Re: Variadic aggregates vs. project policy
От | Tom Lane |
---|---|
Тема | Re: Variadic aggregates vs. project policy |
Дата | |
Msg-id | 10483.1377815374@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Variadic aggregates vs. project policy (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Variadic aggregates vs. project policy
|
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: