10.03.2023 03:26, Tom Lane wrote:
Joseph Koshakow<kosh...@gmail.com> writes:
Also I removed some dead code from the previous patch.
That's a little weird, or maybe even a lot weird, but it's not
inherently nonsensical so I'm hesitant to stop accepting it.
However, if UNITS acts that way, then why is ISOTIME different?
So I'm inclined to remove ISOTIME's lookahead check
if (i >= nf - 1 ||
(ftype[i + 1] != DTK_NUMBER &&
ftype[i + 1] != DTK_TIME &&
ftype[i + 1] != DTK_DATE))
return DTERR_BAD_FORMAT;
and rely on the ptype-still-set error at the bottom of the loop
to complain about nonsensical cases.
I also wonder how the units affect time zone parsing.
With the patch:
SELECT time with time zone '010203m+3';
ERROR: invalid input syntax for type time with time zone: "010203m+3"
But without the patch:
SELECT time with time zone '010203m+3';
01:02:03+03
Though with "non-unit" spec:
SELECT time with time zone '010203mmm+3';
01:02:03-03
(With or without the patch.)
It seems like "units" were just ignored in a time zone specification,
but now they are rejected.
At the same time, I see that the time zone specification allows for any
letters with the +/- sign following:
SELECT time with time zone '010203anyletters+3';
01:02:03-03
It's definitely a separate issue, I just want to note a new erroneous
condition.
Best regards,
Alexander
