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
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 |