"Joel Burton" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])