Re: Problems with avg on interval data type

> > Single-field signed integers (and unsigned integers?) must be acceptable
> > for a time zone specification (pretty sure this is covered in the SQL
> > spec).
> 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