Hitoshi Harada <umi.tanuki@gmail.com> writes:
> 2009/11/16 Andrew Gierth <andrew@tao11.riddles.org.uk>:
> "Hitoshi" == Hitoshi Harada <umi.tanuki@gmail.com> writes:
>>> �Hitoshi> �- SortGroupClause.implicit
>>> �Hitoshi> "implicit" member was added in SortGroupClause. I didn't
>>> �Hitoshi> find clear reason to add this. Could you show a case to
>>> �Hitoshi> clarify this?
>>
>> So the code sets "implicit" for any SortGroupClause that is added for
>> some internal reason rather than being present in the original query,
>> and the deparse code in ruleutils skips such clauses.
> I don't have much experiences in VIEW systems, but isn't it enough to
> let "order by x" omitted?
I agree with Hitoshi that this seems to be a hack to deal with the
consequences of a bad design decision. We just recently cleaned up
an ancient mistake of the same sort (having the parser add clauses
to ORDER BY/DISTINCT that the user didn't write) and I don't care
to repeat that error in aggregates.
If it's necessary to decorate the aggregate with additional clauses in
order to make the executor work, the proper place to do that is the
planner. The reason this division of labor is worth preserving is
that if there are alternative implementations that might reasonably be
chosen, the planner is the place to make that choice. Nailing down
sort order in the parser is pre-judging something the planner might
wish to change. (As an example, the reason we had to fix the ORDER
BY/DISTINCT mistake was that it was constraining the planner's choices
about substituting hash aggregation for sort/unique.)
regards, tom lane