Re: Allow to_date() and to_timestamp() to accept localized names

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Arthur Zakirov <zaartur(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allow to_date() and to_timestamp() to accept localized names
Date: 2020-01-24 15:24:15
Message-ID: b7f37b12-3c59-e5d7-0e59-535a117d259b@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-24 16:07:50 Re: Error message inconsistency
Previous Message Tom Lane 2020-01-24 15:24:11 Re: Busted(?) optimization in ATAddForeignKeyConstraint