Martijn van Oosterhout wrote:
> 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";
Given your (previous) comment clarifying STRICT, this is
clearly the way to go. It "tolerates" errors in the
CREATE FUNCTION statements. Granted, the user can still
screw up the definition so that things don't *work*
properly... but, he can't strip off some protections
that STRICT affords a function *written* with those
expectations.
(I don't care if the software "doesn't work"... I just
have to make sure the server isn't compromised in the
process)
Thanks!
--don