Re: ISSTRICT behavior - Mailing list pgsql-general

Tom Lane wrote:
> Don Y <pgsql@DakotaCom.Net> writes:
>> Is there any way of mimicking the IS STRICT behavior
>> *without* declaring the function as "STRICT"?
>
> Are you looking for PG_RETURN_NULL()?  If not, this seems a bit
> nonsensical.

No.

First, if the function is defined to return an INT16,
then returning a NULL doesn't make any sense -- since the
caller doesn't know how to deal with a NULL (it expects
an INT16, for example).  It is my understanding that
returning NULL doesn't abort the call chain, etc.
So, the NULL has to be handled as a return value... in
a place that is expecting an INT16 (in this case).

What I am trying to do is make functions more robust.
As it stands currently, the functions get written and
compiled "once".  Thereafter, someone can FAIL to
specify STRICT when creating those functions in SQL
(CREATE FUNCTION...) and leave the server vulnerable
to having those functions invoked with NULL arguments.

I can PG_ARGISNULL(x) in each function and issue an
error if I detect that the function is being invoked
with a NULL (this code would be superfluous if the
function was declared as STRICT -- since it would never
have been invoked at all!).  But, I am assuming that
this just generates the message but doesn't otherwise
prevent/abort the function call (the function wouldn't
have been invoked if it had been STRICT so the whole
process would have never been started).  So, while I
may have explicitly protected this function, I now have
to return something (some VALUE) that remains consistent
with the expectations of anything that invokes this
function (e.g., some bogus value that is at least the
correct *type*).

I.e. there is no way to abort the "computation" (from
within the function that detects the invocation with NULL)

>> Lastly, am I correct in assuming that the STRICT
>> modifier only protect a function from being invoked
>> with a NULL _from_the_SQL_interface?  I.e. does it
>> also protect the function from being invoked from
>> PL/pgsql?  (I'm sure it does NOT protect from a
>> deliberate invocation from a C language function, etc.)
>
> If a caller fails to check this (directly or indirectly),
> it's the caller's bug not the callee's.  To say otherwise
> would require introducing ARGISNULL checks into literally
> thousands of places.  There are far fewer call sites of
> arbitrary functions, so we put the burden on the callers.

But, specifically, *does* the STRICT modifier apply to
PL/pgsql invocations of functions?  Or, just those
"from the command line" (so to speak).  E.g., if I
invoke a STRICT function with a NULL argument from
within a trigger, will the server core/SEGV?  Or, will
it catch the attempt just like it would if I had
tried to invoke the function in a SELECT statement
issued through psql?