Re: Q: unexpected result from SRF in SQL

Joe Conway <mail@joeconway.com> writes:
> This is an illustration of why the expression SRF API isn't very useful 
> for returning composite types ;)
> The number is actually a pointer to the result row. There is no way 
> under the expression API to get at the individual columns directly.

You can get at one column --- as of 7.3 it is possible to do
SELECT (bar(1)).field2;

(the parens are required to avoid syntax conflicts).  However SELECT is
not bright enough to do anything useful with a composite value directly.

Long ago (ie, in Postquel days) there seems to have been support for
breaking apart a composite result into multiple output columns.
(I *think* that was what the "fjoin" variant of targetlists was for.)
But it's been dead code for a long time --- probably Yu and Chen broke
it while converting the system to use SQL-spec syntax for SELECTs.

I am thinking that in 7.3 we might admit that that code's never gonna
get fixed, and alter SELECT so that a composite result appearing in a
SELECT targetlist draws an error.

If anyone does someday resurrect fjoin-like functionality, a reasonable
SQL-style syntax for invoking it would be
SELECT (bar(1)).*;

which would still leave us wanting to raise an error if you just write
"SELECT bar(1)".
        regards, tom lane