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

Re: patch: bytea_agg

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: bytea_agg
Date: 2011-12-23 21:36:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

2011/12/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Dec 23, 2011 at 2:16 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>> On fre, 2011-12-23 at 13:30 -0500, Robert Haas wrote:
>>>> Well, because it doesn't operate on strings.
>>> Sure, binary strings.  Both the SQL standard and the PostgreSQL
>>> documentation use that term.
>> I'm unimpressed by that argument, but let's see what other people think.
> I generally agree with Peter: string_agg makes sense here.  The only
> real argument against it is Pavel's point that he didn't include a
> delimiter parameter, but that just begs the question why not.  It
> seems at least plausible that there would be use-cases for it.

I don't know a real usage for bytea delimiter. Probably there is, but
I expect so most often use case will be without delimiter. And when it
is necessary, then || should be used. I see two ways:

a) use it bytea_agg as it now
b) use a string_agg with delimiter, that will be usually empty.

Using a string_agg for bytea is not too intuitive (but has sense) -
maybe we can introduce a synonym type for bytea - like "binary string"
or "bstring".



> So I think we should try to make this as much like the text case as
> possible.
>                        regards, tom lane

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-12-23 21:37:20
Subject: Re: WIP: explain analyze with 'rows' but not timing
Previous:From: Tom LaneDate: 2011-12-23 21:22:01
Subject: Re: WIP: explain analyze with 'rows' but not timing

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