Re: Record returning function accept not matched columns declaration

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, February 29, 2024, PetSerAl <petseral@gmail.com> wrote:
>> postgres=# with a(b) as (values (row(1,2,3)))
>> postgres-# select * from a, coalesce(b) as c(d int,e int, f int)
>> postgres-# union all
>> postgres-# select * from a, nullif(b, null) as c(d int,e int, f int)
>> postgres-# union all
>> postgres-# select * from a, unnest(array[b]) as c(d int,e int, f int)
>> postgres-# union all
>> postgres-# select * from a, json_populate_record(b, null) as c(d int,e
>> int, f int); --expect OK

> My concern with all of this is accepting the specification of column
> definitions for functions that don’t return the record pseudo-type.

Hm?  These cases all *do* return record, because that's what a.b is
typed as.

It looks to me like we broke these edge cases in refactoring.
v11 gives me the expected errors:

regression=# with a(b) as (values (row(1,2,3)))
select * from a, nullif(b, null) as c(d int,e int);
ERROR:  function return row and query-specified return row do not match
DETAIL:  Returned row contains 3 attributes, but query expects 2.
regression=# with a(b) as (values (row(1,2,3)))
select * from a, coalesce(b) as c(d int,e int);
ERROR:  function return row and query-specified return row do not match
DETAIL:  Returned row contains 3 attributes, but query expects 2.

v12 rejects the nullif example but not coalesce.  v14 and up lets them
both by.  I think the v14 change has to do with the function calls
having got flattened to constants, but I've not fingered the exact
culprit yet.  I didn't look yet for the earlier behavioral change.

Even more amusing, since v14:

regression=# with a(b) as (values (row(1,2,3)))
select * from a, coalesce(b) as c(d int,e int,f int, g int);
server closed the connection unexpectedly

I think that Assert is just wrong and can be removed, though;
it doesn't seem to be guarding anything of interest.

			regards, tom lane