Re: RFD: schemas and different kinds of Postgres objects - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: RFD: schemas and different kinds of Postgres objects
Date
Msg-id 3C58A472.2E90C21C@tpf.co.jp
Whole thread Raw
In response to Re: RFD: schemas and different kinds of Postgres objects  (Bill Studenmund <wrstuden@netbsd.org>)
Responses Re: RFD: schemas and different kinds of Postgres objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: RFD: schemas and different kinds of Postgres objects  (Bill Studenmund <wrstuden@netbsd.org>)
List pgsql-hackers
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,

I have no objection to the point it makes sense to use
such *path*s internally but I think it also has a siginificance
for SQL-path to not look up _tables_like objects. 
I think they are different from the first and we should(need)
not manage the system with one *path*.

BTW I see few references to *catalog*. Would the concept
of catalog be introduced together. If so what would be
contained in the current database.

regards,
Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Improving backend launch time by preloading relcache
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Re: A simpler way to configure the source code?