Il Thursday 25 October 2007 16:29:33 Scott Marlowe ha scritto:
> On 10/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Joe Conway <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> 1. Treat NULL rowid as a category in its own right. This would
> > >> conform with the behavior of GROUP BY and
On 10/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> 1. Treat NULL rowid as a category in its own right. This would conform
> >> with the behavior of GROUP BY and DISTINCT, for instance.
>
> > In any case, the attached changes the behav
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 1. Treat NULL rowid as a category in its own right. This would conform
>> with the behavior of GROUP BY and DISTINCT, for instance.
> In any case, the attached changes the behavior to #1 for both flavors of
> crosstab (the original cros
Tom Lane wrote:
Jorge Godoy <[EMAIL PROTECTED]> writes:
Em Thursday 18 October 2007 16:37:59 Joe Conway escreveu:
The row is pretty useless without a rowid in this context -- it seems
like the best thing to do would be to skip those rows entirely. Of
course you could argue I suppose that it oug
"Tom Lane" <[EMAIL PROTECTED]> writes:
> 3. Throw a NOTICE or WARNING (hopefully only one message not repeated
> ones) if NULL rowid is seen, then ignore the row.
>From my experience with OLTP I don't like this one. A warning for DML is
effectively the same as an error if you're running thousands
But when re-doing the query now without the JOIN, it works (almost):
SELECT
*
FROM
crosstab(
'SELECT
id_country AS id,
year_start AS year,
value
FROM
agri_area AS d
WHERE
year_start = 2003 OR year_start = 2
Tom Lane wrote:
Jorge Godoy <[EMAIL PROTECTED]> writes:
Em Thursday 18 October 2007 16:37:59 Joe Conway escreveu:
The row is pretty useless without a rowid in this context -- it seems
like the best thing to do would be to skip those rows entirely. Of
course you could argue I suppose that it oug
Jorge Godoy <[EMAIL PROTECTED]> writes:
> Em Thursday 18 October 2007 16:37:59 Joe Conway escreveu:
>> The row is pretty useless without a rowid in this context -- it seems
>> like the best thing to do would be to skip those rows entirely. Of
>> course you could argue I suppose that it ought to thr
Em Thursday 18 October 2007 16:37:59 Joe Conway escreveu:
> Tom Lane wrote:
> > so it's trying to pstrdup a null result from SPI_getvalue.
> >
> > Obviously it shouldn't crash, but I'm not sure what it *should* do in
> > this case. Joe?
>
> The row is pretty useless without a rowid in this context
Tom Lane wrote:
so it's trying to pstrdup a null result from SPI_getvalue.
Obviously it shouldn't crash, but I'm not sure what it *should* do in
this case. Joe?
The row is pretty useless without a rowid in this context -- it seems
like the best thing to do would be to skip those rows entirel
On 10/18/07, Stefan Schwarzer <[EMAIL PROTECTED]> wrote:
> But when re-doing the query now without the JOIN, it works (almost):
>
> SELECT
> *
> FROM
> crosstab(
>'SELECT
> id_country AS id,
> year_start AS year,
> value
> FROM
>
On 10/18/07, Stefan Schwarzer <[EMAIL PROTECTED]> wrote:
> > Could you provide a self-contained test case for this? There's not
> > really enough information here for someone else to duplicate the
> > problem. Also, which PG version are you using?
>
> Wasn't sure what you ment with "a self contai
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> Here is a SQL dump for the table. One can just neglect the JOIN with
> the countries table (which just replaces the country id with the
> country name):
> http://geodata.grid.unep.ch/download/sql_agri_area.sql.zip
> But when re-doing the query now
Could you provide a self-contained test case for this? There's not
really enough information here for someone else to duplicate the
problem. Also, which PG version are you using?
Wasn't sure what you ment with "a self containted test case". Is it
the raw data?
Here is a SQL dump for the ta
Stefan Schwarzer <[EMAIL PROTECTED]> writes:
> I had a couple of problems getting there. But now that I have the
> feeling that this is OK, it tells me this:
> server closed the connection unexpectedly
Could you provide a self-contained test case for this? There's not
really enough information
Hi there,
successfully installed the tablefunc package.
Now, I would like to transform this kind of result based on a normal
SQL:
c_name |year|value
---
Germany | 2001| 123
Germany | 2002| 125
Germany
16 matches
Mail list logo
