From: | "Mike Mascari" <mascarm(at)mascari(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "PostgreSQL" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: HAVING and column alias |
Date: | 2003-02-22 05:36:48 |
Message-ID: | 000701c2da34$652d0900$0102a8c0@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Mike Mascari <mascarm(at)mascari(dot)com> writes:
> > SELECT
> > SUM(p.qty),
> > (SELECT date_trunc('day', sales.active)
> > FROM sales
> > WHERE sales.purchase = p.purchase) AS field1
> > FROM purchases p
> > GROUP BY field1
> > HAVING (field1 IS NOT NULL);
>
> > ERROR: Attribute 'field1' not found
>
> This is definitely illegal per the SQL spec: output column
names are not
> legal per spec in either GROUP BY or HAVING. Postgres is lax
about this
> in GROUP BY (mainly for historical reasons), but not in
HAVING --- and
> even in GROUP BY, we only recognize an output column name if
it is used
> by itself, not as part of an expression. So your HAVING
clause would
> lose even if we applied GROUP-BY-like rules to it.
Okay. I wasn't sure. It appears as a 'feature' tested by mySQL's
crashme, which is obviously not a measurement of SQL spec
compliance, to be sure...
> If you can't restructure the query, I think you'll have to
repeat the
> sub-SELECT in the HAVING clause rather than refer to it via
the field1
> alias.
Okay. I'll have to upgrade, then. Repeating the sub-SELECT in
the HAVING clause generated that same error that I reported
earlier when two sub-SELECTs in the target list are identical in
version 7.2.1.
Thanks, Tom
Mike Mascari
mascarm(at)mascari(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-22 07:53:06 | Re: optimizer bent on full table scan |
Previous Message | Joshua Drake | 2003-02-22 05:25:38 | Re: What filesystem? |