"David Blewett" <[EMAIL PROTECTED]> writes:
> Here's a vote for allowing this in plain SQL.
> I use the tablefunc contrib module as a way to build a view of a
> specific questionnaire's responses (using Elein's nice model here
> [1]). Currently, if I then write queries against these views that
> include WHERE clauses they don't perform very well as the underlying
> data size grows. I was using the afore-mentioned large view that casts
> everything to text, but recently I started using separate calls to the
> crosstab function for each underlying table, then joining them
> together based on their response ID. This seems to work much better
> for more complex queries, but I think it would still be beneficial to
> have access to these qualifiers so I could push down to each subquery
> the list of response ID's to pull. I don't have access to sample SQL
> at the moment, but if it is wanted I can try to get that this week.
Please. Some real use-cases would be very helpful here. I'm
particularly wondering whether the proposed deparse call actually yields
anything that's useful without extensive additional knowledge about
the query ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
