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
-
Fix type-checking of RECORD-returning functions in FROM.
- d769f9d97feb 13.15 landed
- a595c3075fb4 14.12 landed
- 466376c9f848 12.19 landed
- 3b671dcf53d1 15.7 landed
- 2ed8f9a01e74 17.0 landed
- 1b3029be5df0 16.3 landed