Re: Record returning function accept not matched columns declaration

On Thursday, February 29, 2024, PetSerAl <petseral(at)gmail(dot)com> wrote:

> postgres=# SHOW SERVER_VERSION;
> server_version
> ----------------
> 16.2
> (1 row)
>
>
> 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
> b | d | e | f
> ---------+---+---+---
> (1,2,3) | 1 | 2 | 3
> (1,2,3) | 1 | 2 | 3
> (1,2,3) | 1 | 2 | 3
> (1,2,3) | 1 | 2 | 3
> (4 rows)

My concern with all of this is accepting the specification of column
definitions for functions that don’t return the record pseudo-type. This
seems like it should be a syntax error, or better documented how it should
behave. Specifically, for this bug report to make sense, one must assume
that the specification of a column definition composite on a non-record
result must match the actual structure that is seen. The syntax is not a
means to implement a cast of a row-typed value. The fact the last two
examples implement a cast is a bug. One that apparently doesn’t manifest
for set-returning functions in the from clause but does manifest for
non-SRF laterally applied functions.

David J.