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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-12-10T00:26:02Z
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

Commits

  1. Seek zone abbreviations in the IANA data before timezone_abbreviations.

  2. Make pg_interpret_timezone_abbrev() check sp->defaulttype too.