...
> Well done and a million thanks to whoever implemented it such that the argument
> to AT TIME ZONE is a SQL statement.
Thanks. Positive feedback is always welcome ;)
> 1. Am I the only one who is surprised by the column name ('timezone' instead of
> 't')? A parser buglet (assuming noise after column name is AS)?
I'm not sure I'd characterize this as a bug(let), though since it led to
unexpected behavior maybe it is by definition?
Anyway, what happens under the covers in the initial phase of the parser
is that this SQL9x construct is converted to a function call, which
happens to be
timezone(tz, t)
The output of this function is a character string with a time and time
zone. By the time the parser hits the "what should we call this column?"
part of the code the fact that you didn't actually specify the
timezone() function call is already lost. It would be a bit misleading
to simply call the column "t", since it isn't really just "t", but "t"
evaluated at a specific time zone and then converted to a string. So I'm
not sure I have a suggestion as to what to call the column if we didn't
call it "timezone".
> 2. Is this really supposed to work? More precisely: can I count on it if future
> releases? The documentation
> (http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-select.html) does not
> mention it....
Sure. Well, very likely anyway. AT TIME ZONE is defined in SQL9x, so we
are likely to continue to support it.
- Thomas
