Re: HAVING and column alias

Поиск
Список
Период
Сортировка
От Mike Mascari
Тема Re: HAVING and column alias
Дата
Msg-id 000701c2da34$652d0900$0102a8c0@mascari.com
обсуждение исходный текст
Ответ на HAVING and column alias  (Mike Mascari <mascarm@mascari.com>)
Ответы Re: HAVING and column alias
Список pgsql-general
From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Mike Mascari <mascarm@mascari.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@mascari.com





В списке pgsql-general по дате отправления:

Предыдущее
От: jd@commandprompt.com (Joshua Drake)
Дата:
Сообщение: Re: What filesystem?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: optimizer bent on full table scan