Single-field signed integers (and unsigned integers?) must be acceptable
for a time zone specification (pretty sure this is covered in the SQL
But surely there is other context cuing you that the number is a
timezone? In any case, you weren't proposing that interval_in
should accept '8' as a timezone ...
In the particular case I mentioned, any context is gone by the time the
parser gets beyond gram.y (and that is well before the constant is
evaluated). The general point is that in this case (and perhaps some
other cases) there is a need to convert an interval into a time zone, so
the specification of either or both had better be self consistant.

We do not have an explicit timezone type which could make different
assumptions about units on unadorned integers (and I'd like to avoid
defining a new type for this purpose since SQL9x seems to think that
"interval" should be enough). I'd also like to avoid *requiring* the
full brain damage of SQL9x interval specifications such as Peter
mentioned; we may support it, but should not require it since it is
truely horrid.

- Thomas

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 8 | next ›
Discussion Overview
grouppgsql-bugs @
postedMay 17, '01 at 7:24p
activeMay 19, '01 at 6:21a



site design / logo © 2021 Grokbase