From: | Octavio Alvarez <alvarezp(at)alvarezp(dot)ods(dot)org> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Pet Peeves? |
Date: | 2009-01-31 23:54:10 |
Message-ID: | 1233446050.5647.73.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, 2009-01-31 at 23:36 +0000, Gregory Stark wrote:
> Octavio Alvarez <alvarezp(at)alvarezp(dot)ods(dot)org> writes:
>
> > A crosstab is not but a presentational transform of the data set. Any
> > information you would eventually need can be taken from the original
> > data source, one way or another. That's why dynamic-column crosstab are
> > not a problem, and the DBMS should not worry about providing the
> > information about the columns, maybe by simply not allowing the
> > dynamic-column ones in subqueries.
>
> What about a WHERE clause like
>
> WHERE P1 > P2
You could either:
(1) do "FROM grades AS g1 INNER JOIN grades AS g2 ON g1.P1 > g2.P2",
generating the record set before applying the crosstab transformation.
(2) Since you are implying the existence of P1 and P2, use the
fixed-number-of-columns crosstab case instead, for which PG would
actually be able to give the column definitions without running the
query, and after that, joining the results with some other query.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Murphy | 2009-02-01 00:52:31 | Re: Indices types, what to use. Btree, Hash, Gin or Gist |
Previous Message | Cliff Pratt | 2009-01-31 23:47:53 | Re: [GENERAL] Encoding problem using pg_dumpall |