At 01:12 25/01/00 -0500, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>>>> SQL in general doesn't believe that tuple ordering has any semantic
>>>> significance --- you can ask for ORDER BY, but that's only honored
>>>> at the end stage of SELECT result delivery, not necessarily anywhere
>>>> in the bowels of a query.
>
>> Out of curiosity, does the SQL spec give any rules or guidelines about when
>> aggregates should be applied to resultant rows? Or is it one of the
>> implementation-dependant things?
>
>Well, SQL's conceptual model is perfectly clear about the processing
>work flow of a SELECT: after you've constructed the tuple set (which
>might involve joining multiple relations), you apply the WHERE condition
>to filter out uninteresting tuples. Then you apply GROUP BY (if given)
>to divvy the tuples into groups. Then you apply HAVING to eliminate
>uninteresting groups. Then you apply aggregate functions (if any) to
>individual groups, or to the whole filtered result set if no groups.
>Finally you apply ORDER BY to whatever's left.
Thanks, but now I'm confused. I would have thought that aggregates went
*before* the having clause, since at least one DB I know allows:
select job_type,avg(age) from <wherever> where <stuff> group by job_type
having avg(age) > 70;
ie. the use of aggregate results in the 'having' clause.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/