Appetite for syntactic sugar to match result set columns to UDT fields?

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Appetite for syntactic sugar to match result set columns to UDT fields?
Date: 2025-09-05 05:50:11
Message-ID: CAKFQuwaNf4Zc3XV0Zy_MUA2AobJ2+=K8_+iLUY31fuQXgwcbag@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, September 4, 2025, Philip Warner <pjw(at)rhyme(dot)com(dot)au> wrote:

> *The Solution*
>
> Some syntax like:
>
> SELECT CAST((F1=> value1, F2 => value2) AS FOO BY NAME)
>
> or
>
> SELECT FOO(F1 => VALUE1, F2=> value2);
>
> or some other well-defined and non-conflicting syntax.
>

Don’t really see the point of new syntax here - both things you wrote are
already effectively syntactically valid if a user-defined function exists;
and it’s a cleaner interface. Plus, the serialized form of a composite
doesn’t include field names so giving those names special treatment
elsewhere feels excessive.

Expanding cast with custom features seems particularly undesirable.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alyona Vinter 2025-09-05 05:51:12 Re: Resetting recovery target parameters in pg_createsubscriber
Previous Message vignesh C 2025-09-05 05:49:54 Re: Logical Replication of sequences