Re: Record returning function accept not matched columns declaration

On Thursday, February 29, 2024, PetSerAl <petseral@gmail.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.