Re: [HACKERS] Drop one-argument string_agg? (was Re: string_agg delimiter having no effect with order by)

On 4 August 2010 23:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Hm?  I don't think that an initdb here would have any impact on whether
>> we can call the next drop RC1 or not.  We're talking about removing a
>> single built-in entry in pg_proc --- it's one of the safest changes we
>> could possibly make.
>
> Well, I forgot that an aggregate involves more than one catalog row ;-).
> So it's a bit bigger patch than that, but still pretty small and safe.
> See attached.
>
> What we are doing here, IMO, is not just changing string_agg() but
> instituting a project policy that we are not going to offer built-in
> aggregates with the same names and different numbers of arguments ---
> otherwise the problem will come right back.  Therefore, the attached
> patch adds an opr_sanity regression test that will complain if anyone
> tries to add such.  Of course, this isn't preventing users from creating
> such aggregates, but it's on their own heads to not get confused if they
> do.

Yes, I think that's sensible.

>
> This policy also implies that we are never going to allow default
> arguments for aggregates, or at least never have any built-in ones
> that use such a feature.
>
> By my count the following people had offered an opinion on making
> this change:
>        for: tgl, josh, badalex, mmoncure
>        against: rhaas, thom
> Anybody else want to vote, or change their vote after seeing the patch?
>
>                        regards, tom lane
>
>

I was afraid that the function would be pulled completely, but from
looking at the patch, you're only removing the function with a
single-parameter signature, which is quite innocuous. So I'm "for"
now.
--
Thom Brown
Registered Linux user: #516935