Re: Record returning function accept not matched columns declaration

On Sat, Mar 2, 2024 at 1:56 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I wrote:
> > I think we just need to flip things around so that we build the
> > expected tupdesc from coldeflist if it's present, and only if not do
> > we examine the expression. The cases this might fail to catch should
> > all have been handled at parse time in addRangeTableEntryForFunction,
> > so we don't have to check again.
>
> Here's a draft patch that fixes it that way.
>
> I'm having mixed feelings about whether to back-patch this. Somebody
> might complain that we broke a working query in a minor release.

context: in postgres 9.3.25, dbfiddle[1]
this query will fail:
`
with a(b) as (values (row(1,2,3)))
select * from a, coalesce(b) as c(d int, e int);
`

+ * Note that if the function returns a named composite type, that may
+ * now contain more or different columns than it did when the plan was
+ * made. For both that and the RECORD case, we need to check tuple
+ * compatibility. ExecMakeTableFunctionResult handles some of this,
+ * and CheckVarSlotCompatibility provides a backstop.
*/

I think by ExecMakeTableFunctionResult you mean `mainly
ExecMakeTableFunctionResult's function: tupledesc_match`
since ExecMakeTableFunctionResult is quite long.

also looking around the code, `ExecMakeTableFunctionResult handles
some of this,`
actually is `ExecMakeTableFunctionResult handles most of this`?

So overall, I think `ExecMakeTableFunctionResult's inner function,
tupledesc_match handle most of this`
would be more accurate.

[1] https://dbfiddle.uk/4SrE-1JR