Skip site navigation (1) Skip section navigation (2)

Re: RFD: schemas and different kinds of Postgres objects

From: Bill Studenmund <wrstuden(at)netbsd(dot)org>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFD: schemas and different kinds of Postgres objects
Date: 2002-01-31 16:26:40
Message-ID: Pine.NEB.4.33.0201310823050.29090-100000@vespasia.home-net.internetconnect.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 31 Jan 2002, Hiroshi Inoue wrote:

> Tom Lane wrote:
> >
> > Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > 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*.

I'm confused. Are you suggesting multiple paths? i.e. a function/type path
and a table one?

I think calling our path an SQL path is fine. Yes, we extend it by using
it for tables too, but it strikes me as still fundamentally an SQL path.
So I don't see why we should not call it that.

Take care,

Bill


In response to

pgsql-hackers by date

Next:From: Bill StudenmundDate: 2002-01-31 16:28:10
Subject: Re: RFD: schemas and different kinds of Postgres objects
Previous:From: Andy RuhlDate: 2002-01-31 16:13:38
Subject: Re: postgresql under Windows is slow

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group