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

From Tom Lane
Subject Re: Schemas: status report, call for developers
Date
Msg-id 22827.1020777113@sss.pgh.pa.us
Whole thread Raw
In response to Re: Schemas: status report, call for developers  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List pgsql-hackers
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> I see there are routines doing similar things but for functions and
> others. I'm right in saying that OID isn't unique in a database
> (necessarily) and so we couldn't have a general object_is_visible(oid)
> function that did the appropiate from the type of object refered to?

Not in the current structure.  Even if OID were guaranteed unique across
the database, how would you determine which kind of object a given OID
referred to?  Seems like it would take expensive probing of a lot of
different tables until you found a match --- which is a bit silly when
the calling query generally knows darn well where it got the OID from.

I suppose we could define an object_is_visible(tableoid, oid) function,
but I'm not sure if it has any real usefulness.

> It just seems that if we're interested in showing tables according to
> visibility then shouldn't we be doing the same for these other things?

Sure; if we go this routine then all five of the FooIsVisible routines
will need to be exported as SQL functions.
        regards, tom lane


pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: OK, lets talk portability.
Next
From: Tom Lane
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports