Re: Record returning function accept not matched columns declaration

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: jian he <jian.universality@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, PetSerAl <petseral@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2024-03-04T00:40:01Z
Lists: pgsql-bugs
jian he <jian.universality@gmail.com> writes:
> On Sat, Mar 2, 2024 at 1:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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);

Sure, but in v12 and up (i.e., the supported versions that we might
back-patch into) the query succeeds, and it might not be obvious
to someone that its behavior isn't as-intended.

Admittedly, this seems like a rather contrived case.  In cases
where the record-returning function call isn't reducible to a
constant, you'll get the expected error.  So maybe I'm worrying
over something that no one is depending on in practice.

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

Perhaps.  I mentioned ExecMakeTableFunctionResult because that's
what's called directly from nodeFunctionscan.c.  Referencing a
static function of another module is risky because it's pretty
unlikely the comment would get updated if refactoring in that
module makes it false.

			regards, tom lane



Commits

  1. Fix type-checking of RECORD-returning functions in FROM.