Re: regclass without error?

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: regclass without error?
Date: 2011-01-04 09:07:41
Message-ID: 20110104.180741.851808052382219450.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-01-04 09:43:20 Re: back branches vs. VS 2008
Previous Message Dimitri Fontaine 2011-01-04 08:46:07 Re: Upgrading Extension, version numbers