On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
<[email protected]> wrote:
> On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov
> <[email protected]> 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
