Re: [HACKERS] Bug in to_timestamp().

On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>>
>> The current version of patch doesn't really distinguish spaces and
>> delimiters in format string in non-FX mode. So, spaces and delimiters
>> are forming single group. For me Oracle behavior is ridiculous at
>> least because it doesn't allow cases when input string exactly matches
>> format string.
>>
>> This one fails:
>> SELECT to_timestamp('2018- -01 02', 'YYYY- -MM DD') FROM dual
>
> Related to below - since this works today it should continue to work. I was under the wrong impression that we followed their behavior today and were pondering deviating from it because of its ridiculousness.

Right, that's just incompatibility with Oracle behavior, not with our
previous behavior.

>> > The couple of regression tests that change do so for the better. It would be illuminating to set this up as two patches though, one introducing all of the new regression tests against the current code and then a second patch with the changed behavior with only the affected tests.
>>
>> OK, here you go. 0001-to_timestamp-regression-test-v17.patch
>> introduces changes in regression tests and their output for current
>> master, while 0002-to_timestamp-format-checking-v17.patch contain
>> changes to to_timestamp itself.
>>
>
> From those results the question is how important is it to force the following breakage on our users (i.e., introduce FX exact symbol matching):
>
> SELECT to_timestamp('97/Feb/16', 'FXYY:Mon:DD');
> - to_timestamp
> -------------------------------
> - Sun Feb 16 00:00:00 1997 PST
> -(1 row)
> -
> +ERROR: unexpected character "/", expected character ":"
> +HINT: In FX mode, punctuation in the input string must exactly match the format string.
>
> There seemed to be some implicit approvals of this breakage some 30 emails and 10 months ago but given that this is the only change from a correct result to a failure I'd like to officially put it out there for opinion/vote gathering. Mine is a -1; though keeping the distinction between space and non-alphanumeric characters is expected.

Do I understand correctly that you're -1 to changes to FX mode, but no
objection to changes in non-FX mode?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company