I've attached new version of the patch. It is a little bit simpler now than the previous one.
The patch doesn't handle backslashes now, since there was a commit which fixes quoted-substring handling recently.
Anyway I'm not sure that this handling was necessary.
I've checked queries from this thread. It seems that they give right timestamps and work like in Oracle (except
differentmessages).
The patch contains documentation and regression test fixes.
On Sun, Nov 19, 2017 at 12:26:39PM -0500, Tom Lane wrote:
> I don't much like the error message that you've got:
>
> +SELECT to_timestamp('97/Feb/16', 'FXYY:Mon:DD');
> +ERROR: unexpected character "/", expected ":"
> +DETAIL: The given value did not match any of the allowed values for this field.
>
> The DETAIL message seems to have been copied-and-pasted into a context
> where it's not terribly accurate. I'd consider replacing it with
> something along the lines of "HINT: In FX mode, punctuation in the input
> string must exactly match the format string." This way the report will
> contain a pretty clear statement of the new rule that was broken. (BTW,
> it's a hint not a detail because it might be guessing wrong as to what
> the real problem is.)
>
> regards, tom lane
Messages have the following format now:
SELECT to_timestamp('97/Feb/16', 'FXYY:Mon:DD');
ERROR: unexpected character "/", expected ":"
HINT: In FX mode, punctuation in the input string must exactly match the format string.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
