Re: Record returning function accept not matched columns declaration

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-02-29 21:55:55
Message-ID: CAKFQuwbXwwPbwtZ5FDGix1R-XXmvynfi+hcjSKZYk1ifegVbcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Feb 29, 2024 at 2:31 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

>
> 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.
>
>
Hit send too soon...

I suppose this entire query form is basically a hack around the fact that
we have no syntax to directly assign names to the fields of an "anonymous
record type" literal.

with a(b) as (values (row(1,2,3)))
select (a.b).* from a;
ERROR: record type has not been registered

Though oddly this doesn't seem to be universal:

with a(b) as (values (row(1,2,3)))
select (row(c.*)).* from a, coalesce(a.b) as c (d int, e int, f int);
f1, f2, and f3 end up being the output field names...

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PetSerAl 2024-02-29 22:01:31 Re: Record returning function accept not matched columns declaration
Previous Message David G. Johnston 2024-02-29 21:31:36 Re: Record returning function accept not matched columns declaration