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.
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 |