"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.
I strongly dislike the seemingly overloaded terminology in this area. Namely I was trying to distinguish these two example function signatures.
json_populate_record ( base anyelement, from_json json ) → anyelement
jsonb_to_record ( jsonb ) → record
Polymorphic functions do not require a column definition list. The non-polymorphic function signature does require the column definition list. That we accept a column definition list in the polymorphic case is settled code but seems like it led to this bug.
