Re: Schemas: status report, call for developers - Mailing list pgsql-hackers

From Nigel J. Andrews
Subject Re: Schemas: status report, call for developers
Date
Msg-id Pine.LNX.4.21.0205062004110.2674-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: Schemas: status report, call for developers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Schemas: status report, call for developers  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Schemas: status report, call for developers  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List pgsql-hackers
On Mon, 6 May 2002, Tom Lane wrote:

> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > Coming back to this subject if I may but only briefly, I hope. How
> > about making a slight change to current_schemas() and including an
> > optional argument such that something like:
> >  current_schemas(1)
> > returns the complete list of schemas in the search path including the
> > implicit temporary space and the pg_catalog (if not already listed
> > obviously), while current_schemas() and current_schemas(0) behave as
> > now.
> 
> I don't really care for that syntax, but certainly we could talk about
> providing a version of current_schemas that tells the Whole Truth.
> 
> > Having something like this would enable client's like PgAccess to
> > determine the complete list of visible objects.
> 
> Well, no, it wouldn't.  Say there are multiple tables named foo in
> different namespaces in your search path (eg, a temp table hiding a
> permanent table of the same name).  A test like "where current_schemas
> *= relnamespace" won't reflect this correctly.
> 
> I'm suspecting that what we really need is some kind of
> "is_visible_table()" test function, and then you'd do
>     select * from pg_class where is_visible_table(oid);
> At least I've not been able to think of a better idea than that.

Ok, where I was coming from was the idea of the client, I'm most interested in
PgAccess at the moment, retrieving the search path and cross referencing that
against the results of the queries for tables etc.

I seemed to remember mention of an is_visible() function earlier in the thread
but that for some reason this would mean a performance hit across the board, or
at least in many places. However, reviewing my emails I see not such comment
about performance. Tom originally suggested relation_is_visible(oid) as the
function.

I also got it wrong about when the temporary space is emptied. I had been
thinking it was when the connection terminated. However, I see from the same
old message that this happens when the first temporary item is created in a
session. Therefore, my way would be invalid anyway; or would it?


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Next
From: Tom Lane
Date:
Subject: Re: Schemas: status report, call for developers