On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston <david.g.johns...@gmail.com> wrote: > On Mon, Sep 3, 2018 at 2:30 PM, Alexander Korotkov > <a.korot...@postgrespro.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