Re: Record returning function accept not matched columns declaration

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: PetSerAl <petseral(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Record returning function accept not matched columns declaration
Date: 2024-03-06 20:09:09
Message-ID: 301471.1709755749@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> with a(b) as (values (row(1,2,3)))
> select (a.b).* from a;
> ERROR: record type has not been registered

I looked into this case. The failure occurs when the parser tries
to expand the ".*" notation into separate output columns, as required
per SQL spec. All it has is a Var of type RECORD referencing the
VALUES RTE entry, so it has to fail.

In the specific example given here, you could imagine drilling down
into the VALUES and figuring out what concrete rowtype the RECORD
value will have at runtime, but I'm not excited about going there.
There are too many cases where it wouldn't work.

Note that as long as you don't need parse-time expansion of the
record, it works:

=# with a(b) as (values (row(1,2,3)))
select a.b from a;
b
---------
(1,2,3)
(1 row)

I pushed the patch for the original problem. After debating with
myself I concluded that back-patching it was probably less risky
than not back-patching, so I did that.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Korotkov 2024-03-06 20:24:03 Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
Previous Message Tom Lane 2024-03-06 19:52:28 Re: BUG #18379: LDAP bind password exposed