Re: BUG #18470: Time literal accepted in Postgres 15 and below, not accepted in Postgres 16

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18470: Time literal accepted in Postgres 15 and below, not accepted in Postgres 16
Дата
Msg-id 2473625.1715968911@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #18470: Time literal accepted in Postgres 15 and below, not accepted in Postgres 16  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #18470: Time literal accepted in Postgres 15 and below, not accepted in Postgres 16  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
I wrote:
> I'm not sure whether that wikipedia page should be taken
> as authoritative, but if we can convince ourselves that
> 'T14:00:00' really is a thing per 8601, then yeah we should
> undo that part.

Given the lack of ready availability of 8601 itself, perhaps
we should assume that everyone's going to believe wikipedia.
In any case, what it says is pretty straightforward:

    As of ISO 8601-1:2019, the basic format is T[hh][mm][ss] and the
    extended format is T[hh]:[mm]:[ss]. Earlier versions omitted the T
    (representing time) in both formats.

    Either the seconds, or the minutes and seconds, may be omitted
    from the basic or extended time formats for greater brevity but
    decreased precision; the resulting reduced precision time formats
    are:

    T[hh][mm] in basic format or T[hh]:[mm] in extended format, when
    seconds are omitted.

    T[hh], when both seconds and minutes are omitted.

We previously accepted all of these except T[hh].  I'm inclined
to continue to reject that, even if it's nominally standards
compliant, because it seems way too likely to be a mistake.

Interestingly, the code does still take the "basic" (colon-free)
forms:

regression=# select time 'T1347';
   time   
----------
 13:47:00
(1 row)

regression=# select time 'T134712';
   time   
----------
 13:47:12
(1 row)

regression=# select time 'T134712.4';
    time    
------------
 13:47:12.4
(1 row)

So at this point, yeah that's a bug we should fix.
I'll look into it later if nobody beats me to it.

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18472: SELECT FOR UPDATE locking more rows than expected
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics