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

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> Well, it's not insane on its face. The rowtype of f in the
> Tom> first example is necessarily a built-on-the-fly record, but in
> Tom> the second case using the properties of the underlying named
> Tom> composite type is possible, and consistent with what happens in
> Tom> 9.3 and earlier. (Not that I'm claiming we were or are totally
> Tom> consistent ...)

> Right, but your changes to the code make it look like there was an
> intended change there - with the scan type tupdesc being forced to
> RECORD type and its column names changed.

I did set things up so that if you have a RECORD result, the column names
will be those of the query's alias list; this was in response to the
comment in the patch that complained that we were inconsistent about where
we were getting the names from if you had a mix of named-composite
functions and other functions. I believe what is happening in the case
you show is that the function is returning a composite Datum that's marked
with the composite type's OID, and the upstream consumers are looking at
that, not at the scan tupdesc. I'm not really excited about tracing down
exactly what the data flow is ...

regards, tom lane