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
