Hi,
This example in the docs declares a function returning an anonymous
2-component record:
CREATE FUNCTION dup(in int, out f1 int, out f2 text)
AS $$ SELECT $1, CAST($1 AS text) || ' is text' $$
LANGUAGE SQL;
The same declaration can be changed to have just one OUT parameter:
CREATE FUNCTION dup(in int, out f text)
AS $$ SELECT CAST($1 AS text) || ' is text' $$
LANGUAGE SQL;
But it then behaves as a function returning a text scalar, not a record.
It is distinguishable in the catalog though; it has prorettype text,
proallargtypes {int,text}, proargmodes {i,o}, proargnames {"",f}.
The first declaration can have RETURNS RECORD explicitly added (which
doesn't change its meaning any).
If RETURNS RECORD is added to the second, this error results:
ERROR: function result type must be text because of OUT parameters
Is that a better outcome than saying "ah, the human has said what he means,
and intends a record type here"? It seems the case could easily be
distinguished in the catalog by storing record as prorettype.
Perhaps more surprisingly, the RETURNS TABLE syntax for the set-returning
case has the same quirk; RETURNS TABLE (f text) behaves as setof text
rather than setof record. Again it's distinguishable in the catalog,
this time with t in place of o in proargmodes.
In this case, clearly the meaning of RETURNS TABLE with one component
can't be changed, as it's already established the way it is, but the
equivalent syntax with one OUT parameter and RETURNS RECORD is currently
rejected with an error just as in the non-SETOF case, so would it not
be equally feasible to just allow that syntax and let it mean what it says?
Regards,
-Chap
In passing, I also noticed RETURNS TABLE () is a syntax error. I have
no use case in mind for a function returning an empty composite result,
but I note that we do allow zero-column tables and empty composite types.
And it still has 1 bit of entropy: you can tell an empty composite value
from a null.