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

Re: patch: bytea_agg

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: bytea_agg
Date: 2012-04-07 14:38:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On ons, 2012-04-04 at 18:59 -0400, Tom Lane wrote:
>> Uh, no.  That test is there for good and sufficient reasons, as per its
>> comment:

> 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).

The point of the policy is to be sure that we will throw a specific
error message with a suitable hint when a malformed call is made.
If there are alternative aggregates in the catalogs that have the
potential to "capture" such a call, then we risk the wrong thing
happening.  It appears that the lack of any implicit cast from bytea to
text would prevent that today, but I still think this proposal boxes
us in to an unreasonable degree compared to the benefit.  For example,
this would greatly restrict our ability to throw "ambiguous aggregate"

> 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.)

Hm.  So are you now suggesting we should get rid of one-argument
bytea_agg and replace it with two-argument string_agg(bytea,bytea)?
I could support that, since we've not released bytea_agg yet.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Noah MischDate: 2012-04-07 15:50:42
Subject: Re: ECPG FETCH readahead
Previous:From: Michael MeskesDate: 2012-04-07 11:20:08
Subject: Re: ECPG FETCH readahead

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