From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone. |
Date: | 2014-07-22 03:27:44 |
Message-ID: | 5100.1405999664@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> Though pondering this additionally the actual coding to make -0400 be
> interpreted as "-4:00" would indeed be a feature enhancement - though
> accepting a result of 400 I would argue is a bug even if it is one we are
> going to choose to live with in back branches for compatibility reasons. We
> seem to already agree that it should at least error out on a going-forward
> basis.
The fact that it crashes is indisputably a bug (fixed as of a few minutes
ago). However, whether SET TIMEZONE = '-0400' should be read as setting
the UTC offset to 400 hours, or 400 minutes, or 400 seconds, or 4 hours,
or who knows what else, is not a bug, it's a definitional disagreement.
As a comparison point, the syntax SET TIME ZONE INTERVAL '-0400' is
specified in the SQL standard, and unless I'm totally misreading it, the
standard requires that to be interpreted as 400 minutes. (The standard's
examples of useful values look more like '-04:00'.) Now that might look
silly on its face, but if the string is '-180' then reading it as UTC
minus 3 hours doesn't seem so silly.
Anyway, we could certainly have a discussion about changing the
interpretation, but it would not be a back-patchable bug fix IMO.
There's a non-negligible risk of breaking apps that worked before.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-07-22 05:42:06 | Re: BUG #10972: string_agg function incorrectly concatenating varying delimiter |
Previous Message | Amit Kapila | 2014-07-22 03:17:19 | Re: [BUGS] BUG #9652: inet types don't support min/max |