10.03.2023 03:26, Tom Lane wrote:
> Joseph Koshakow<koshy44@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