Re: Exposed function to find table in schema search list?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joel Burton" <joel(at)joelburton(dot)com>
Cc: "Pgsql-Hackers(at)Postgresql(dot) Org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Exposed function to find table in schema search list?
Date: 2002-05-24 17:33:14
Message-ID: 12824.1022261594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joel Burton" <joel(at)joelburton(dot)com> writes:
> Well, sort of, but if we had been promoting a function tableoid(text)
> returns oid, we wouldn't have to make any change for the move to regclass,
> would we? I mean, it's specific to PG, but a simple wrapper might outlive
> the next under-the-hood change.

I think you miss the point: regclass is that wrapper. tableoid(text)
is only syntactically different --- and for that matter there's nothing
stopping you from writing regclass('tablename').

> On a related note: is there an easy way to use this ::regclass conversion to
> test if a table exists in a non-error returning way? (Can I use it in a
> select statement, for instance, returning a true or false value for the
> existence or non-existence of a table?)

At the moment regclass conversion raises an error if the item isn't
found; this follows the historical behavior of regproc. We could
possibly have it return 0 (InvalidOid) instead, but I'm not convinced
that that's better. In the case of regproc, not erroring out would
lose some important error checking during initdb.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gunther Schadow 2002-05-24 17:43:36 Alternatives to SQL ...
Previous Message Joe Conway 2002-05-24 17:27:18 Re: Redhat 7.3 time manipulation bug