Re: Variadic aggregates vs. project policy

On 2013-08-29 18:29:34 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-08-29 15:55:13 -0400, Tom Lane wrote:
> >> For context see the thread starting here:
> >> http://www.postgresql.org/message-id/AANLkTikV5ok2tS8t6V+gsAPtE3N6TJq1JpPhMZhG2XL0@mail.gmail.com
> >> In that thread we agreed that this "policy" might be rather squishy,
> >> but we should at least think hard about whether it would be wise to create
> >> built-in aggregates with the same name and different numbers of arguments.
> 
> > I vote for abolishing that policy or maybe weakinging it. As you comment
> > somewhere downthread the policy just prohibits core functions, but even
> > for those it looks too strong for me. There are some useful variadic
> > aggregates I'd like to see and I don't think that the kind of errors
> > prevented by the policy are frequent enough to warrant a blanket
> > prohibition.
> 
> Well, I dunno.  We had two different "bug reports" caused by this type of
> confusion before string_agg even got out of beta, both from intelligent
> people.  So I'm not about to discount the potential for confusion.
> 
> As we said originally, this is a policy that might be broken for
> sufficiently strong cause --- but I don't want to just forget about
> the risks.

> > I'd say we let the check in there but have a list of exceptions in it so
> > that one has to explicitly think about the issue before adding the
> > function.
> 
> That's pretty much how the tests in opr_sanity work now.

I basically mean that we should adapt the paragraph you quoted upthread
to roughly say something like:

-- Check that there are not aggregates with the same name and different
-- numbers of arguments. For many aggregates - look for string_agg in
-- the archives for an example - the risk of confusing novices, which
-- place ORDER BY in the wrong place, seems too big. If an aggregate is
-- deemed not to be likely to cause such a problem or provides a feature
-- which doesn't seem possibly to provide in another way that, add an
-- excception for it.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services