Andres Freund 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 20 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 29, '13 at 7:55p
activeAug 31, '13 at 3:02a
posts20
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2017 Grokbase