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