Re: RFD: schemas and different kinds of Postgres objects - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: RFD: schemas and different kinds of Postgres objects
Date
Msg-id 3C58BBB3.58D5F964@tpf.co.jp
Whole thread Raw
In response to Re: RFD: schemas and different kinds of Postgres objects  (Bill Studenmund <wrstuden@netbsd.org>)
Responses Re: RFD: schemas and different kinds of Postgres objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: RFD: schemas and different kinds of Postgres objects  (Bill Studenmund <wrstuden@netbsd.org>)
List pgsql-hackers
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.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


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: freebsd postgres port
Next
From: Tom Lane
Date:
Subject: Re: RFD: schemas and different kinds of Postgres objects