Search Postgresql Archives

Re: ISSTRICT behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Lane wrote:
Don Y <pgsql@xxxxxxxxxxxxx> 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?


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux