From: Tom Lane <tgl@sss.pgh.pa.us>
To: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Arthur Zakirov <zaartur@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Allow to_date() and to_timestamp() to accept localized names
Date: Fri, 24 Jan 2020 10:20:30 -0500
Message-ID: <28023.1579879230@sss.pgh.pa.us> (raw)
In-Reply-To: <CAC+AXB1fQtg-iWH=4qZnV0xYm08WR6W7AhoApKA3tkFsWgf90A@mail.gmail.com>
References: <20200123164955.GA23074@alvherre.pgsql>
<20326.1579816853@sss.pgh.pa.us>
<CAC+AXB1fQtg-iWH=4qZnV0xYm08WR6W7AhoApKA3tkFsWgf90A@mail.gmail.com>
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <juanjo.santamaria@gmail.com> writes:
> On Thu, Jan 23, 2020 at 11:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * It's not exactly apparent to me why this code should be concerned
>> about non-normalized characters when noplace else in the backend is.
> 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.
Works for me.
> * I have no faith in this calculation that decides how long the match
>> length was:
>> *len = element_len + name_len - norm_len;
> The proper logic would come from do_to_timestamp() receiving a normalized
> "date_txt" input, so we do not operate with unnormalize and normalize
> strings at the same time.
No, that only solves half the problem, because the downcasing
transformation can change the string length too. Two easy examples:
* In German, I believe "ß" downcases to "ss". In Latin-1 encoding that's
a length change, though I think it might accidentally not be in UTF8.
* The Turks distinguish dotted and dotless "i", so that "İ" downcases to
"i", and conversely "I" downcases to "ı". Those are length changes in
UTF8, though not in whichever Latin-N encoding works for Turkish.
Even if these cases happen not to apply to any month or day name of
the relevant language, we still have a problem, arising from the fact
that we're downcasing the whole remaining string --- so length changes
after the match could occur anyway.
> I would like to rise a couple of questions myself:
> * When compiled with DEBUG_TO_FROM_CHAR, there is a warning "‘dump_node’
> defined but not used". Should we drop this function or uncomment its usage?
Maybe, but I don't think it belongs in this patch.
> * Would it be worth moving str_tolower(localized_name)
> from seq_search_localized() into cache_locale_time()?
I think it'd complicate tracking when that cache has to be invalidated
(i.e. it now depends on more than just LC_TIME). On the whole I wouldn't
bother unless someone does the measurements to show there'd be a useful
speedup.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, juanjo.santamaria@gmail.com, alvherre@2ndquadrant.com, zaartur@gmail.com, tomas.vondra@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Allow to_date() and to_timestamp() to accept localized names
In-Reply-To: <28023.1579879230@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox