Re: postgres_fdw fails because GMT != UTC

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: postgres_fdw fails because GMT != UTC
Date: 2024-04-04 09:08:32
Message-ID: F9A3C95E-FA62-4040-94F4-3BA52D5CA3A7@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 4 Apr 2024, at 08:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Over at [1] we have a complaint of postgres_fdw failing with
> a remote-server error
>
>> ERROR: invalid value for parameter "TimeZone": "UTC"
>
> I am not quite clear on how broken an installation needs to be to
> reject "UTC" as a time zone setting, except that the breakage cannot
> be subtle. However, I notice that our code in pgtz.c and other
> places treats "GMT" as a hard-wired special case ... but not "UTC".
> I wonder if we ought to modify those places to force "UTC" down the
> same hard-wired paths. If we acted like that, this would have worked
> no matter how misconfigured the installation was.

+1. It makes little sense to support GMT like that but not UTC.

> An alternative answer could be to change postgres_fdw to send "GMT"
> not "UTC". That's ugly from a standards-compliance viewpoint, but
> it would fix this problem even with a non-updated remote server,
> and I think postgres_fdw is generally intended to work with even
> very old remote servers.

There is always a risk in accomodating broken installations that it might hide
other subtle bugs, but off the cuff that risk seems quite low in this case.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2024-04-04 09:08:40 Re: ExecAppendAsyncEventWait() in REL_14_STABLE can corrupt PG_exception_stack
Previous Message Masahiko Sawada 2024-04-04 09:05:02 Re: Introduce XID age and inactive timeout based replication slot invalidation