Re: TimestampTz->Text->TimestampTz casting fails with DateStyle 'Postgres'

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: TimestampTz->Text->TimestampTz casting fails with DateStyle 'Postgres'
Date: 2024-12-10 00:26:02
Message-ID: Z1eKmoJHXVd8_oz1@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Nov 07, 2024 at 06:09:15PM +0300, Aleksander Alekseev wrote:
> Here is the patch.

@@ -139,6 +139,7 @@ static const datetkn datetktbl[] = {
{"july", MONTH, 7},
{"jun", MONTH, 6},
{"june", MONTH, 6},
+ {"lmt", IGNORE_DTF, 0}, /* "lmt" (throwaway) */
{"m", UNITS, DTK_MONTH}, /* "month" for ISO input */
{"mar", MONTH, 3},
{"march", MONTH, 3},

FWIW, I have a hard time understanding why ignoring "LMT", which is
a timezone abbreviation meaning "Local Mean Time", in datetktbl[],
which is a table for date/time keywords, is the right thing to do.

The comment at the top of datetktbl also mentions that this includes
no TZ, DTZ, or DYNTZ entries, and that we should rely on zoneabbrevtbl
instead, which is pushed by InstallTimeZoneAbbrevs() depending on the
GUC assign callback of timezone_abbreviations. So that seems just
inconsistent to me. Perhaps that's OK at the end, but this ignores
the existing comment on top of the table.

Worth noting that we may want to do something in ECPG's dt_common.c as
well, that holds a similar table with TZ abbreviation data and LMT is
missing there?
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-12-10 02:12:32 Re: TimestampTz->Text->TimestampTz casting fails with DateStyle 'Postgres'
Previous Message Tom Lane 2024-12-09 21:51:51 Re: pg_dump crash on identity sequence with not loaded attributes