On 4 August 2010 23:19, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers