Re: How to use result column names in having cause

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "chris smith" <dmagick(at)gmail(dot)com>
Cc: Andrus <eetasoft(at)online(dot)ee>, pgsql-general(at)postgresql(dot)org
Subject: Re: How to use result column names in having cause
Date: 2006-03-31 15:59:56
Message-ID: 8689.1143820796@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"chris smith" <dmagick(at)gmail(dot)com> writes:
> I assume it's this way because the standard says so..

Right. From a logical point of view, the HAVING clause has to be
evaluated before the output expressions are computed, so it doesn't
make any sense to expect the output expressions to be available in
HAVING. An example of why this must be so is
SELECT x, 1/avg(y) FROM TAB GROUP BY x HAVING avg(y) > 0
If the HAVING clause isn't executed first this may fail with zero-divide
errors.

The real bug here IMHO is that we don't enforce the same rule for
GROUP BY. Allowing "GROUP BY 1" to reference an output column is
a violation of the spec, which I think we adopted basically because
some other DBMSes do it too, but it's just as semantically nonsensical
as doing it in HAVING would be. It's a wart on the language that we
can't really get rid of because of backwards-compatibility
considerations, but we're highly unlikely to add more such warts.

BTW, if you're really intent on not writing your big expression twice,
use a sub-select:
SELECT x
FROM (SELECT big_expr AS x FROM ...) AS ss
GROUP BY ...
HAVING x > ...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Steve Atkins 2006-03-31 16:24:10 Re: pgsql continuing network issues
Previous Message Ian Harding 2006-03-31 15:46:26 Re: PostgreSQL x Sybase