Re: Inconsistent behavior on select * from void_function()? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconsistent behavior on select * from void_function()?
Date
Msg-id 22160.1173748814@sss.pgh.pa.us
Whole thread Raw
In response to Inconsistent behavior on select * from void_function()?  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> Why is a function which returns void returning a row?

Returning a scalar result that happens to be of type VOID is an entirely
different thing from returning a set result that contains no rows.

> Why is that row 
> NULL if it's a SQL function and empty if it's a PLPGSQL function?

I'd say that the SQL function is probably doing the right thing.  It
appears that plpgsql has hacked this specially "for backward
compatibility":
   /*    * Special hack for function returning VOID: instead of NULL, return a    * non-null VOID value.  This is of
dubiousimportance but is kept for    * backwards compatibility.  Note that the only other way to get here is    * to
havewritten "RETURN NULL" in a function returning tuple.    */   if (estate->fn_rettype == VOIDOID)   {
estate->retval= (Datum) 0;       estate->retisnull = false;       estate->rettype = VOIDOID;   }
 

I haven't tested, but I think that diking out this section would make
the result be a null (still of type void).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values
Next
From: "Andrew Dunstan"
Date:
Subject: Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values