On lör, 2012-04-07 at 10:38 -0400, Tom Lane wrote:
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
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-04-07 at 10:38 -0400, Tom Lane wrote:
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.
Yes,
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.
Peter Eisentraut pete...@gmx.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
On fre, 2011-12-23 at 19:51 +0200, Peter Eisentraut wrote:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it string_agg? All the function names are the same between
text and bytea (e.g.,
Peter Eisentraut pete...@gmx.net writes:
On fre, 2011-12-23 at 19:51 +0200, Peter Eisentraut wrote:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
Why not call it string_agg?
Here is a patch to do the renaming. As it stands, it fails the
On Wed, Apr 4, 2012 at 11:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The renaming you propose would only be acceptable to those who have
forgotten that history. I haven't.
I had. I looked it up
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00044.php
That was quite a thread.
--
greg
On Fri, Dec 23, 2011 at 12:30 PM, Robert Haas robertmh...@gmail.com wrote:
Well, because it doesn't operate on strings.
I argued when we added string_agg that it ought to be called
concat_agg, or something like that, but I got shouted down. So now
here we are.
+1. Using the input type
On Thu, Dec 22, 2011 at 11:49 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 21, 2011 at 5:04 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Looks fine to me. I'll commit this, barring objections.
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it string_agg? All the function names are the same between
text and bytea (e.g., ||, substr, position, length). It would be nice
not to introduce
Hello
2011/12/23 Peter Eisentraut pete...@gmx.net:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it string_agg? All the function names are the same between
text and bytea (e.g., ||, substr,
Hello
2011/12/23 Peter Eisentraut pete...@gmx.net:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it string_agg? All the function names are the same between
text and bytea (e.g., ||, substr,
On Fri, Dec 23, 2011 at 12:51 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it string_agg? All the function names are the same between
text and
On fre, 2011-12-23 at 13:30 -0500, Robert Haas wrote:
On Fri, Dec 23, 2011 at 12:51 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it
On Fri, Dec 23, 2011 at 2:16 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-12-23 at 13:30 -0500, Robert Haas wrote:
On Fri, Dec 23, 2011 at 12:51 PM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg
Robert Haas robertmh...@gmail.com wrote:
Peter Eisentraut pete...@gmx.net wrote:
Robert Haas wrote:
Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Why not call it
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 23, 2011 at 2:16 PM, Peter Eisentraut pete...@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
Hello
2011/12/23 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 23, 2011 at 2:16 PM, Peter Eisentraut pete...@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
Pavel Stehule pavel.steh...@gmail.com wrote:
maybe we can introduce a synonym type for bytea - like binary
string or bstring.
The standard mentions these names for binary strings:
BINARY, BINARY VARYING, or BINARY LARGE OBJECT
which have a certain symmetry with:
CHARACTER, CHARACTER
Excerpts from Pavel Stehule's message of vie dic 23 18:36:11 -0300 2011:
Hello
2011/12/23 Tom Lane t...@sss.pgh.pa.us:
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
On Wed, Dec 21, 2011 at 5:04 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Looks fine to me. I'll commit this, barring objections.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Hello
this patch adds a bytea_agg aggregation.
It allow fast bytea concatetation.
Regards
Pavel Stehule
*** ./doc/src/sgml/func.sgml.orig 2011-12-07 11:04:33.0 +0100
--- ./doc/src/sgml/func.sgml 2011-12-21 11:00:18.255753111 +0100
***
*** 10911,10916
--- 10911,10934
22 matches
Mail list logo