Re: Record returning function accept not matched columns declaration

On Thu, Feb 29, 2024 at 1:11 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Thursday, February 29, 2024, PetSerAl <petseral(at)gmail(dot)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.

David J.