Re: BUG #17860: Possible Bugs in PL/pgSQL Functions' Return Values - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17860: Possible Bugs in PL/pgSQL Functions' Return Values
Date
Msg-id 1496421.1679494751@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17860: Possible Bugs in PL/pgSQL Functions' Return Values  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Mar 22, 2023 at 6:15 AM PG Bug reporting form <
> noreply@postgresql.org> wrote:
>> Moreover, regarding function test2(), the result is also perplexing.
>> According to the documentation,
>> "Data type void Indicates that a function returns no value."
>> 
>> Therefore, it is reasonable to expect that the returned value should be an
>> empty table, as it should not be returning any value. However, in reality,
>> it returns a table with one row.

> The system retains the data type "void" for that singular value as the
> representation of the fact that the function that was called did not itself
> return any particular value.

"void" is a bit of a hack.  As far as the system is concerned, it's
an actual scalar type, having no operations and exactly one value,
which prints as an empty string.  The point of doing that rather than
just returning (say) an empty string is the lack of operations: if you
accidentally try to do something with the result of a void-returning
function, it'll fail because void can't be coerced to anything else.

As David says, this is not the same as a set result containing
zero rows.

            regards, tom lane



pgsql-bugs by date:

Previous
From: John Naylor
Date:
Subject: Re: operator class "xxx" does not exist for access method "yyy"
Next
From: PG Bug reporting form
Date:
Subject: BUG #17861: Disappearance of packages in repo for rhel-8