From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Variadic aggregates vs. project policy |
Date: | 2013-08-29 22:29:34 |
Message-ID: | 10483.1377815374@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-08-29 22:30:04 | WAL CPU overhead/optimization (was Master-slave visibility order) |
Previous Message | Andres Freund | 2013-08-29 22:25:46 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |