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
