Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison |
Дата | |
Msg-id | 199910052216.SAA29400@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
|
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> However, I can't see anything in the SQL92 spec that requires you to > >> use HAVING intelligently, so maybe this error should be downgraded to > >> a notice? "HAVING with no aggregates would be faster as a WHERE" > >> (but we'll do it anyway to satisfy pedants...) > > > If we allow them, then people can do things like: > > HAVING max(a) > b > > Er ... what's wrong with that? Assuming b is a group by column, > of course... But can we compare aggs and non-aggs? I see now that our code is fine: select relowner from pg_class group by relowner having max(relowner) = relowner; This returns the proper result, namely the relowner _having_ the max id. Having is using an aggregate and non-aggregate, so when I said we only support aggregates in the HAVING clause, I was wrong. Looks fine. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: