Skip site navigation (1) Skip section navigation (2)

Re: patch: bytea_agg

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: bytea_agg
Date: 2012-04-07 10:52:00
Message-ID: 1333795920.26334.7.camel@vanquo.pezone.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On ons, 2012-04-04 at 18:59 -0400, Tom Lane wrote:
> 
> >> Why not call it string_agg?
> 
> > Here is a patch to do the renaming.  As it stands, it fails the
> > opr_sanity regression test, because that complains that there are now
> > two aggregate functions string_agg with different number of arguments.
> > It seems to me that that test should really only complain if the common
> > argument types of the two aggregates are the same, correct?
> 
> Uh, no.  That test is there for good and sufficient reasons, as per its
> comment:
> 
> -- Check that there are not aggregates with the same name and different
> -- numbers of arguments.  While not technically wrong, we have a project policy
> -- to avoid this because it opens the door for confusion in connection with
> -- ORDER BY: novices frequently put the ORDER BY in the wrong place.
> -- See the fate of the single-argument form of string_agg() for history.
> 
> The renaming you propose would only be acceptable to those who have
> forgotten that history.  I haven't.

I had reviewed that thread very carefully, but I'm not sure it applies.
The issue was that we don't want aggregates with optional second
argument, because "novices" could confuse

agg(a, b ORDER BY c)

with

agg(a ORDER BY b, c)  -- wrong

without the error being flagged.

But that doesn't apply if the first argument has different types.
Erroneously calling agg(textdatum ORDER BY textdatum, sthelse) will not
result in a call to agg(bytea).  (Unless the textdatum is really an
unknown literal, but that would be silly.)

Nevertheless, the problem would now be that adding string_agg(bytea)
would effectively forbid adding string_agg(bytea, delim) in the future.
So making a two-argument string_agg(bytea, bytea) now seems like the
best solution anyway.  (This applies independently of the function
renaming, actually.)



In response to

Responses

pgsql-hackers by date

Next:From: Atri SharmaDate: 2012-04-07 11:07:36
Subject: Regarding GSoc Application
Previous:From: Peter EisentrautDate: 2012-04-07 10:13:23
Subject: Re: pg_upgrade improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group