Re: BUG #17860: Possible Bugs in PL/pgSQL Functions' Return Values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: jiangshan(dot)liu(at)tju(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17860: Possible Bugs in PL/pgSQL Functions' Return Values
Date: 2023-03-22 14:19:11
Message-ID: 1496421.1679494751@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wed, Mar 22, 2023 at 6:15 AM PG Bug reporting form <
> noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-03-22 15:50:28 BUG #17861: Disappearance of packages in repo for rhel-8
Previous Message John Naylor 2023-03-22 14:12:56 Re: operator class "xxx" does not exist for access method "yyy"