Re: patch: bytea_agg - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: patch: bytea_agg
Date
Msg-id CAFj8pRAm4hRWRJ+2KfXJ3JvQMwX-KXWty6uitK7kYjtVu=GQ9w@mail.gmail.com
Whole thread Raw
In response to Re: patch: bytea_agg  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: patch: bytea_agg
Re: patch: bytea_agg
List pgsql-hackers
Hello

2011/12/23 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Dec 23, 2011 at 2:16 PM, Peter Eisentraut <peter_e@gmx.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".

Regards

Pavel


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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: explain analyze with 'rows' but not timing
Next
From: Pavel Stehule
Date:
Subject: Re: WIP: explain analyze with 'rows' but not timing