On Wed, 30 Jan 2002, Tom Lane wrote:
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Bill Studenmund wrote:
> >> While we may have not been using the terminology of the spec, I think we
> >> have been talking about schema paths from SQL99.
> >>
> >> One difference between our discussions and SQL99 I've noticed is that
> >> we've spoken of having the path find functions (and operators and
> >> aggregates), types, _and_tables_.
>
> > My understanding is the same.
> > Tom, Peter is it right ?
>
> SQL99's SQL-path is very clearly stated to be used only for looking up
> routines and user-defined type names. Extending it to cover tables,
> operators, and so forth makes sense to me, but we have to recognize
> that it is a spec extension and therefore not all the answers we need
> can be found in the spec.
True. I think that extending the path to be used for operators and
aggregates makes sense as they are special types of function calls. The
searching for tables might need to be a configurable parameter (defaulting
to yes), though. I think it makes sense to do, but I can imagine cases
where apps need to not.
> I also find it curious that they exclude standard type names from the
> search path. It would seem obvious to treat the standard type names
> as included in a schema that is part of the search path, but AFAICT
> this is not done in the spec. Postgres *has to* do it that way,
> however, or give up our whole approach to datatypes; surely we don't
> want to hardwire the SQL-standard datatypes into the parser to the
> exclusion of the not-so-standard ones.
>
> IMHO, the spec's artificial distinction between system and user types
> limits its usefulness as a guide to the questions we're debating here.
True.
Does SQL99 support types as flexable as the ones we do? I know types in
Oracle are basically special cases of already built-in ones...
Take care,
Bill
