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: | CAFj8pRAm4hRWRJ+2KfXJ3JvQMwX-KXWty6uitK7kYjtVu=GQ9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
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".
Regards
Pavel
>
> So I think we should try to make this as much like the text case as
> possible.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-12-23 21:37:20 | Re: WIP: explain analyze with 'rows' but not timing |
Previous Message | Tom Lane | 2011-12-23 21:22:01 | Re: WIP: explain analyze with 'rows' but not timing |