I am working on date/time stuff, and in the spirit of cleaning up
interesting but marginally useful features I've dropped support for
"invalid" for the timestamp and timestamptz types. 

To help with upgrading, I thought that I'd map it to a NULL value, and
see the following in the regression tests:

-- Obsolete special values
INSERT INTO TIMESTAMP_TBL VALUES ('invalid');
ERROR:  OidFunctionCall3: function 1150 returned NULL

Is this error message a feature of all returns of NULL, particular to
input routines, or can I somehow mark routines as being allowed to
return NULL values?

Comments?

                        - Thomas

Thu, 20 Sep 2001 02:01:51 +0000
Thomas Lockhart <lockhart@fourpalms.org>
Returning NULL from functions
Thomas Lockhart <lockhart@fourpalms.org> writes:
> ERROR:  OidFunctionCall3: function 1150 returned NULL

> Is this error message a feature of all returns of NULL, particular to
> input routines, or can I somehow mark routines as being allowed to
> return NULL values?

It's a "feature" for all places that invoke SQL functions via the
FooFunctionCallN routines.  The API for those routines offers no way
to handle passing or returning NULL, so they have little choice but to
raise elog(ERROR) if they see the called function return NULL.

Those routines are intended for use in places where a NULL result is
nonsensical anyway, and so extending their API to allow NULL would just
create useless notational clutter.  If you want to cope with NULLs then
you have to set up and inspect a FunctionCallInfoData structure for
yourself.  See the comments in backend/utils/fmgr/fmgr.c.

Offhand I see no good reason why a datatype input routine should return
NULL.  Either return a valid value of the type, or elog(ERROR).  IMHO,
NULL is (and should be) an out-of-band value handled by
datatype-independent logic.

			regards, tom lane

Wed, 19 Sep 2001 23:11:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Returning NULL from functions 