Re: Schemas: status report, call for developers

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

On Mon, 6 May 2002, Tom Lane wrote:

> "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> writes:
> > For this if we look once again at RelnameGetRelid(relname) in
> > backend/catalog/namespace.c wouldn't this is_visible() function simply be a
> > wrapper around it?
>
> Sort of. It's there already, see RelationIsVisible.
>

Doh. Next function down.

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?

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?

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Shevlakov 2002-05-07 10:48:13 code contribution
Previous Message Bertin, Philippe 2002-05-07 06:34:12 Re: IF- statements in a rule's 'DO INSTEAD SELECT ...'- statement

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2002-05-07 13:11:53 Re: Schemas: status report, call for developers
Previous Message lexx_h 2002-05-07 08:53:54