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.
