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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
