| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Specifying columns returned by a function, when the function is in a SELECT column list? |
| Date: | 2024-11-19 15:55:39 |
| Message-ID: | CAKFQuwbFBn6uV1qczBXOZjd0r=zeH9s1KN4CQD_Nj=Lg17_GLQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Nov 19, 2024 at 8:48 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
> It's trivial to specify columns when a table-returning function is the
> FROM clause, but how does one specify columns when the table-returning
> function is a column in a SELECT clause?
>
You don't/cannot. And with lateral you shouldn't find the need to hack
around it either. Non-scalar function calls in the select clause are now
obsolete.
In the select clause the function call returns a single-column of composite
type with the names of the fields in the composite already known. As the
query scope where you invoke the function you should only use the
composite. If you need to dive into its fields you'd need a subquery -
ideally one that doesn't risk being optimized away due to a
multiple-evaluation hazard.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul Foerster | 2024-11-19 16:11:22 | PostgreSQL 15.9 Update: Partitioned tables with foreign key constraints |
| Previous Message | Ron Johnson | 2024-11-19 15:47:52 | Specifying columns returned by a function, when the function is in a SELECT column list? |