From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Variadic aggregates vs. project policy |
Date: | 2013-08-29 22:04:37 |
Message-ID: | 20130829220436.GA7540@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-08-29 22:04:43 | Re: PL/pgSQL PERFORM with CTE |
Previous Message | Pavel Stehule | 2013-08-29 22:04:08 | Re: PL/pgSQL PERFORM with CTE |