From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Hanks <christopher(dot)m(dot)hanks(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Retrieving multiple columns from a subquery |
Date: | 2012-05-15 03:36:58 |
Message-ID: | 11172.1337053018@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Chris Hanks <christopher(dot)m(dot)hanks(at)gmail(dot)com> writes:
> Nothing? Are subqueries just not meant to be used this way?
The SQL standard says not ;-).
You could approximate it like this:
select ..., (select row(x,y,z) from ...), ... from ...;
as long as you don't mind pulling the composite-value output syntax
apart. This avoids the single-output-column syntactic restriction
by cramming all the values into one column.
[ thinks for a bit... ] It seems like you ought to be able to get PG
to pull the composite values apart again, with something like
select ..., (x).*, ... from
(select ..., (select row(x,y,z) from ...) as x, ...
from ... offset 0) ss;
but when I try this I get
ERROR: record type has not been registered
That's a bug, probably, but dunno how hard to fix. In the meantime you
could work around it by casting the row() expression to a named
composite type; which might be a good idea anyway since there's no other
obvious way to control the column names that will be exposed by the
(x).* expansion.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | björn lundin | 2012-05-15 06:04:47 | Re: Uppercase to lowercase trigger? |
Previous Message | Merlin Moncure | 2012-05-15 03:30:07 | Re: Retrieving multiple columns from a subquery |