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
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. |
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 |