Re: regclass without error? - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: regclass without error?
Date
Msg-id 20110104.180741.851808052382219450.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: regclass without error?  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: regclass without error?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Long time ago, I propose regclass like function which does not throw
an error if the table is not found. Instead I want to let it return
InvalidOid or NULL.

>> Tatsuo Ishii <ishii@postgresql.org> writes:
>> > Is there any way to use regclass without having ERROR?
>> 
>> > pgpool-II needs to find the oid from table name and for the purpose it
>> > issues something like "SELECT 'table_name'::regproc::oid". Problem is,
>> > if the table does not exist, an error occured and the transaction
>> > aborts. Ideally if the table does not exist, the SELECT returns 0
>> > (InvalidOid).
>> 
>> I don't think the cast should act that way, but I could see providing a
>> separate conversion function that returns 0 ... or perhaps better NULL
>> ... if no match.
> 
> Such a function should be very helpfull. Great!

I made pretty simple function for this. Essential part is something
like this:

Datum
pgpool_regclass(PG_FUNCTION_ARGS)
{char        *pro_name_or_oid = PG_GETARG_CSTRING(0);Oid    result;
PG_TRY();{    result = DirectFunctionCall1(regclassin,
CStringGetDatum(pro_name_or_oid));}PG_CATCH();{   result = InvalidOid;}PG_END_TRY();
 
PG_RETURN_OID(result);
}

IMO this implementation is the least invasive but not so
elegant.

Before proposing more complete patches, I would like to hear comments:
which way I should go? The least invasive one like above? Or Should I
refactor regclassin, for example implementing "regclassin_gut" which
do the essential job, and making wrapper functions, one is active
existing regclass, and the other act as new one?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Upgrading Extension, version numbers
Next
From: Magnus Hagander
Date:
Subject: Re: back branches vs. VS 2008