Skip site navigation (1) Skip section navigation (2)

Re: [BUGS] Bug in 6.4.2. Aggregate/View/Where-condition

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Cogdon <chris(at)felidae(dot)apana(dot)org(dot)au>
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: [BUGS] Bug in 6.4.2. Aggregate/View/Where-condition
Date: 2000-02-28 22:40:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Chris Cogdon <chris(at)felidae(dot)apana(dot)org(dot)au> writes:
> On Mon, 28 Feb 2000, Tom Lane wrote:
>> regression=# select * from span where min > 3;

> Note that under 6.4 and 6.5, the result of a aggregate (or a subquery,
> even) has to be on the RHS Of an operator. Viz:
> The fact that this error does not come up in 7 either means that they've
> fixed a limitation,

They (that is, I) fixed it.  However, that's just a removal of
one small limitation in code that's fundamentally bogus to start
with :-(.  The rewriter's entire approach to aggregates that it
inserts into WHERE is wrong.

> Can you try it with
> select * from span where 3<min;
> and see what you get.

The same thing.

> Okay... here's a test under 6.5.2:
> test1=> select * from span having 0<min;
> ERROR:  SELECT/HAVING requires aggregates to be valid
> Does this work under 7.beta?


regression=# select * from span having 0<min;
ERROR:  Attribute span.ref must be GROUPed or used in an aggregate function

The appearance of this particular error might represent a fixable bug,
but that's small comfort knowing that the "0 < min" part cannot possibly
work as you want it to.  It's tough to justify putting much effort into
patching small bugs in a chunk of code that I know needs to be thrown
away and rewritten in toto...

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Michael AndreasenDate: 2000-02-28 22:43:04
Subject: No subject was specified.
Previous:From: Chris CogdonDate: 2000-02-28 21:28:52
Subject: Re: [BUGS] Bug in 6.4.2. Aggregate/View/Where-condition

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group