Re: Returning NULL from functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lockhart(at)fourpalms(dot)org
Cc: PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Returning NULL from functions
Date: 2001-09-20 03:11:14
Message-ID: 1160.1000955474@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)fourpalms(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-09-20 03:19:36 Re: type casting troubles
Previous Message Thomas Lockhart 2001-09-20 02:12:34 type casting troubles