From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Bill Studenmund <wrstuden(at)netbsd(dot)org> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: RFD: schemas and different kinds of Postgres objects |
Date: | 2002-01-30 23:55:20 |
Message-ID: | 3C5887E8.CE7E569F@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bill Studenmund wrote:
>
> On Wed, 30 Jan 2002, Hiroshi Inoue wrote:
>
> > Bill Studenmund wrote:
> > >
> > > On Tue, 29 Jan 2002, Hiroshi Inoue wrote:
> > > SQL99 doesn't have tables in there
> > > AFAICT, but I think it makes sense.
> >
> > It seems to make sense but they are different and
> > our *path* is never an extension of SQL-path.
> > Where are the difference or the relevance referred
> > to in this thread ?
>
> How is our path not an extention of SQL-path? Or at least how is the path
> I've been pushing not an SQL-path?
IMHO _tables_like objects must be guarded from such
a search mechanism fundamentally. I don't object to
the use of our *path* but it should be distinguished
from SQL-path.
For example the PATH environment variable is used
only to search executables not files. Is it
preferable for *rm a_file* to search all the directory
in the PATH ? If the purpose is different the different
*path* is needed of cource.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-01-31 00:56:50 | Re: PostgreSQL Final Release ... Monday? |
Previous Message | mlw | 2002-01-30 23:50:49 | Re: Array aggregation. Was: PostgreSQL Final Release ... Monday? |