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 21:28:13
Message-ID: 21395.1022275693@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:
>> 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.

> Fair enough. Is there any way to handle this error and return a false?
> (People frequently ask "how can I check to see if a table exists", and not
> all interfaces handle errors the same way, but everyone should know how to
> deal with a table result, so that we can provide a 7.3 version of "SELECT 1
> FROM pg_class where relname='xxx'".

Well, I have no strong objection to providing an alternate API that
does things that way. I was thinking the other day that we need
text-to-regclass, regclass-to-text, etc conversion functions (these
don't come for free given the I/O routines, sadly enough). Perhaps we
could define, say, text-to-regclass to return NULL instead of throwing
an error on bad input.

This might be a tad awkward to use though, since you'd have to write
something like
'nosuchtable'::text::regclass
or
regclass('nosuchtable'::text)
to get a literal parsed that way rather than fed directly to the
regclass input converter (which we're assuming will still raise an
error).

As far as I'm concerned none of this is set in stone, so I'm open to
better ideas if anyone's got one ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-05-24 21:38:41 Re: Index tuple killing code committed
Previous Message Zeugswetter Andreas SB SD 2002-05-24 21:03:35 Re: Index tuple killing code committed