From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bill Studenmund <wrstuden(at)netbsd(dot)org>, 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 03:36:19 |
Message-ID: | 3C58BBB3.58D5F964@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > 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 unconvinced. We must search for datatypes and tables on the same
> path because tables have associated datatypes;
Isn't the table definition a part of the datatype in
such a case ?
> it will definitely not
> do to look for a table's datatype and get the wrong type. And I think
> that functions and operators should be looked for on the same path
> as datatypes, because a type should be pretty closely associated with
> the functions/operators for it. So it seems to me that the apparent
> flexibility of having more than one path is just a way to shoot yourself
> in the foot. Why are you concerned that we keep them separate?
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 ?
If we would never introduce SQL-paths (in the future)
there would be problem.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-31 03:43:41 | Re: RFD: schemas and different kinds of Postgres objects |
Previous Message | Christopher Kings-Lynne | 2002-01-31 03:17:16 | freebsd postgres port |