From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Don Y <pgsql(at)DakotaCom(dot)Net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ISSTRICT behavior |
Date: | 2006-05-04 07:29:33 |
Message-ID: | 20060504072933.GD4752@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, May 04, 2006 at 12:23:07AM -0700, Don Y wrote:
> I don't want to hide the function; just ensure that no one
> *redefines* the SQL interface to it in a manner that is
> inconsistent with its implementation. If I can make the
> implementation robust enough that it could protect itself
> against this potential, that would be acceptable (hence
> my original question). Barring that, I need to do whatever
> it takes to safeguard the server so that it can't be brought
> to its knees by a simple bug like failing to specify STRICT, etc.
Well, if you really want to, you can do this at the beginning of each
function. It makes it completely fool-proof (until someone finds a
better fool ofcourse).
--- cut ---
if( PG_NARGS != exptectedargs )
die ("bad args" );
for( i=0; i<PG_NARGS; i++ )
{
if( PG_ARGISNULL(i) )
PG_RETURN_NULL();
if( get_fn_expr_argtype( fcinfo->flinfo, i ) != expectedtypes[i] )
die("bad args" );
}
if( get_fn_expr_rettype(fcinfo->flinfo) )
die "bad return type";
--- cut ---
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-05-04 07:36:43 | Re: ISSTRICT behavior |
Previous Message | Don Y | 2006-05-04 07:29:30 | Re: ISSTRICT behavior |