| From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> | 
|---|---|
| To: | "Jim Nasby" <Jim(dot)Nasby(at)BlueTreble(dot)com> | 
| Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>,"Robert Haas" <robertmhaas(at)gmail(dot)com>,"Dean Rasheed" <dean(dot)a(dot)rasheed(at)gmail(dot)com>,"Andres Freund" <andres(at)anarazel(dot)de>,"Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>,"Teodor Sigaev" <teodor(at)sigaev(dot)ru>,"PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [patch] Proposal for \crosstabview in psql | 
| Date: | 2016-03-14 17:18:53 | 
| Message-ID: | d01d39fc-bc16-4d1d-8a45-4f61968ec981@mm | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Jim Nasby wrote:
> Ultimately I'd really like some way to remove/reduce the restriction of 
> result set definitions needing to be determined at plan time. That would 
> open the door for server-side crosstab/pivot as well a a host of other 
> things (such as dynamically turning a hstore/json/xml field into a 
> recordset).
> Ultimately I'd really like some way to remove/reduce the restriction of 
> result set definitions needing to be determined at plan time. That would 
> open the door for server-side crosstab/pivot as well a a host of other 
> things (such as dynamically turning a hstore/json/xml field into a 
> recordset).
That would go against a basic expectation of prepared statements, the
fact that queries can be parsed/prepared without any part of them
being executed.
For a dynamic pivot, but probably also for the other examples you
have in mind, the SQL engine wouldn't be able to determine the output
columns without executing a least a subselect to look inside some
table(s).
I suspect that the implications of this would be so far reaching and
problematic that it will just not happen.
It seems to me that a dynamic pivot will always consist of
two SQL queries that can never be combined into one,
unless using a workaround à la Oracle, which encapsulates the
entire dynamic resultset into an XML blob as output.
The problem here being that the client-side tools
that people routinely use are not equipped to process it anyway;
at least that's what  I find by anecdotal evidence for instance in:
https://community.oracle.com/thread/2133154?tstart=0
 or
http://stackoverflow.com/questions/19298424
 or
https://community.oracle.com/thread/2388982?tstart=0
Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-03-14 17:23:17 | Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat | 
| Previous Message | Tom Lane | 2016-03-14 17:05:48 | Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat |