Josh Berkus wrote:
> Tom,
>
> > On further reflection, what the "policy" was actually about was not that
> > we should forbid users from creating potentially-confusing aggregates
> > themselves, but only that we'd avoid having any *built in* aggregates with
> > this hazard. So maybe I'm overthinking this, and the correct reading is
> > just that we should have a policy against built-in variadic aggregates.
>
> Yes. I think we can assume that anyone smart enough to create a
> variadic aggregate is smart enough to put ORDER BY in the right place.
I don't think it's a question of "smart enough", but rather how easy it
is to make a mistake. In the referenced thread email, I'm sure many of
us looked at the failing query without realizing what the problem was.
That said, if the question is whether or not to offer variadic
aggregates if they give you the chance to misuse them in this way, the
decision seems quite clear to me. Presumably, in the problematic case
the arguments to the aggregate are going to be constructed
programatically in client code; how would an ORDER BY be accidentally
inserted by such code? If you end up having
someagg('foo','bar','baz' ORDER BY 'qux', 'blarg')
instead of someagg('foo','bar','baz', 'blarg' ORDER BY 'qux')
I think you're going to realize the problem quickly enough.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services