"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
