Hitoshi Harada <umi.tan...@gmail.com> writes: > 2009/11/16 Andrew Gierth <and...@tao11.riddles.org.uk>: > "Hitoshi" == Hitoshi Harada <umi.tan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers