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
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 |