Re: RFD: schemas and different kinds of Postgres objects

Bill Studenmund <wrstuden@netbsd.org>

From: Bill Studenmund <wrstuden@netbsd.org>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2002-01-31T16:33:50Z
Lists: pgsql-hackers
On Thu, 31 Jan 2002, Hiroshi Inoue wrote:

> Tom Lane wrote:
> >
> > Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > > For example, doesn't 'DROP table a_table' drop the
> > > a_table table in a schema in the *path* if there's
> > > no a_table table in the current schema ?
> >
> > Sure.  And that's exactly what it should do, IMHO.
> > Otherwise the notion that you can ignore your private
> > schema (at the front of the path) if you're not using
> > it falls down.  Also, we wouldn't be able to implement
> > temp tables via a backend-local schema at the front of
> > the path.
>
> I don't think it's useful for tables other than temp
> ones and I wouldn't use it other than for temp ones.

I agree.

> When we type 'rm a_file' in a shell environment
> does the *rm* command search the PATH in finding
> the a_file file ? Even though we need to implement
> such a search mechanism we would use another path
> different from the executable search PATH. I don't
> think our *path* is an extension of SQL-path.
>
> I wouldn't complain unless we call the *path*
> as SQL-path or an extension of SQL-path.

I still don't get this. The path we're talking about is the same thing
(with the same envirnment name and operational syntax) as SQL-paths,
except that we use it to find tables too. Why does that make it not an SQL
path?

Take care,

Bill