Re: Schemas: status report, call for developers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Schemas: status report, call for developers
Date: 2002-05-07 13:11:53
Message-ID: 22827.1020777113@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-07 13:25:57 Re: HEADS UP: Win32/OS2/BeOS native ports
Previous Message mlw 2002-05-07 12:42:15 OK, lets talk portability.

Browse pgsql-interfaces by date

  From Date Subject
Next Message Ted Petrosky 2002-05-07 13:19:19 libpq.a out of date
Previous Message Nigel J. Andrews 2002-05-07 10:33:41 Re: Schemas: status report, call for developers