Re: UNNEST with multiple args, and TABLE with multiple funcs

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> The issue is that if you want to dig column type information out
>  Tom> of a function RTE, that won't necessarily work after
>  Tom> preprocess_expression has had its way with the contained
>  Tom> expressions.  That's needed at the very least in
>  Tom> create_functionscan_plan.

> What I was aiming for was to _remove_ any special-case handling of
> coldef lists (post-parser) and use only get_expr_result_type.

[ thinks for awhile... ]  I can see that that would have some value
if we were looking to expand the usage of coldeflists to allow
"record_returning_function(...) AS (coldeflist)" to appear in any
expression context not just function RTEs.  However, I can't get
excited about that as a future feature, for two reasons:

1. IME, functions returning unconstrained RECORD tend to return sets
as well; if you don't know what columns you return, it's unlikely you
know how many rows you return.  So this would only be a sensible
feature addition if we were looking to encourage the use of SRFs outside
the FROM clause.  I'm not sure whether we are going to deprecate that,
but I'm pretty sure we don't want to encourage it.

2. There's a syntactic problem, stemming from the perhaps unfortunate
choice to shoehorn coldeflists into the SQL alias syntax: if you've got      SELECT foo(...) AS ...
it'd be impossible to tell after seeing AS whether what follows is a
coldeflist (which'd need to be parsed as part of the function call)
or a column alias (which'd need to not be).  So this would be a
shift-or-reduce conflict for bison, and I venture that humans would
get confused too.

There are also implementation-level reasons to want to keep this behavior
tied to RTE_FUNCTION RTEs rather than being loose in the expression
tree evaluator: we can much more easily handle RTEs that return a random
collection of columns than we can handle arbitrary rowtypes in
expressions.  In particular, the latter works only with the "blessed
rowtype" hack, which doesn't scale nicely to lots of different rowtypes
used in a session.  And I've always considered that to be strictly a
runtime thing, too --- I don't want the interpretation of parsetrees
to require consulting the anonymous-rowtype cache.

So on the whole, I can't get excited about decoupling coldeflists
from function RTEs.  Even if I were excited about it, I'd see it
as a separate feature unrelated to the stated goals of this patch.
        regards, tom lane