| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bill Studenmund | 2002-01-31 16:28:10 | Re: RFD: schemas and different kinds of Postgres objects |
| Previous Message | Andy Ruhl | 2002-01-31 16:13:38 | Re: postgresql under Windows is slow |