Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iv0oq-0001MW-Ad for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Jan 2020 15:24:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iv0op-0001aS-67 for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Jan 2020 15:24:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iv0oo-0001XT-TW for pgsql-hackers@lists.postgresql.org; Fri, 24 Jan 2020 15:24:22 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iv0ol-0006Te-PI for pgsql-hackers@lists.postgresql.org; Fri, 24 Jan 2020 15:24:22 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 68E5A21BF9; Fri, 24 Jan 2020 10:24:17 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 24 Jan 2020 10:24:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=k0iIfDNG/cPfstlZbXdpld2xz2BFajOIJEPo5i0J/ mI=; b=iuLenxJZIfcL1VoApiHKlKzUDN31GeJYvVAXJk2gLG/ZZVZk3ntIZp0qR uQn2d44JmiKkZ+FmqWFF5kBmXcj8ta7JccPmyPgxQZDH+9q/LvxvkfcZ86EUcqZk Bipq3mxDj+ui+otsvIWmoO8Drp+Ae1vhNUyCa6qqwQK0tQYo8+vgdkyyEM1KfiQR 7MYnpP1p92qLEg+AKyd90Q4W1QXdgbk4QVvUDQWjJp7J1xnS2a4MaJOVzirH7aXm AbA2sCEW15fJbaKTQqAlPRgbtG2mO2kTiHhvwsI2kBvKInfewXV1s/WCbLcrJdqB TEZrrTC16wrCRgMk56MxR46Zr0L7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdeggdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucffohhmrghinhepvdhnughquhgrughrrghnthdrtgho mhenucfkphepleefrddvgedvrddvheehrdduuddvnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhhtsedv nhguqhhurggurhgrnhhtrdgtohhm X-ME-Proxy: Received: from april.pezone.net (p5df2ff70.dip0.t-ipconnect.de [93.242.255.112]) by mail.messagingengine.com (Postfix) with ESMTPA id 1F51B306122F; Fri, 24 Jan 2020 10:24:16 -0500 (EST) Subject: Re: Allow to_date() and to_timestamp() to accept localized names To: Alvaro Herrera , =?UTF-8?Q?Juan_Jos=c3=a9_Santamar=c3=ada_Flecha?= References: <20200124114441.GA5753@alvherre.pgsql> Cc: Tom Lane , Arthur Zakirov , Tomas Vondra , PostgreSQL Hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Fri, 24 Jan 2020 16:24:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200124114441.GA5753@alvherre.pgsql> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-01-24 12:44, Alvaro Herrera wrote: > On 2020-Jan-24, Juan José Santamaría Flecha wrote: > >> There is an open patch that will make the normalization functionality user >> visible [1]. So, if a user can call to_date(normalize('01 ŞUB 2010'), 'DD >> TMMON YYYY') I would vote to drop the normalization logic inside this patch >> altogether. > > I was reading the SQL standard on this point, and it says this (4.2.8 > Universal character sets): > > An SQL-implementation may assume that all UCS strings are normalized > in one of [Unicode normalization forms]. > > which seems to agree with what you're saying. When you interact with glibc locale functions, you essentially have to assume that everything is in NFC. When using ICU locale functions (which we don't here, but just for the sake of argument), then I would expect that ICU does appropriate normalization itself when I call icu_what_month_is_this(string) returns int. So I think it is appropriate to not deal with normalization in this patch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services