Re: RFD: schemas and different kinds of Postgres objects

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

In response to

Responses

Browse pgsql-hackers by date

  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