Re: Date-Time dangling unit fix

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