From: "David E. Wheeler" on
On Jan 25, 2010, at 6:56 AM, Pavel Stehule wrote:

> actualised patch - the name is string_agg

All looks fine except I'm getting this error during initdb:

creating template1 database in /usr/local/pgsql-devel/data/base/1 ... FATAL: could not create unique index "pg_proc_oid_index"
DETAIL: Key (oid)=(3031) is duplicated.
child process exited with exit code 1

Would you mind re-submitting with unique OIDs?

Thanks,

David
--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on
On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> "David E. Wheeler" <david(a)kineticode.com> writes:
>> Because it's an aggregate that cocatenates values. It's not an
>> aggregate that lists things. I also like concat_agg better than
>> string_agg because it's not limited to acting on strings.
>
> But what it *produces* is a string.  For comparison, the
> SQL-standard-specified array_agg produces arrays, but what it
> acts on isn't an array.

This point is well-taken, but naming it string_agg() because it
produces a string doesn't seem quite descriptive enough. We might
someday (if we don't already) have a number of aggregates that produce
an output that is a string; we can't name them all by the output type.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> But what it *produces* is a string. �For comparison, the
>> SQL-standard-specified array_agg produces arrays, but what it
>> acts on isn't an array.

> This point is well-taken, but naming it string_agg() because it
> produces a string doesn't seem quite descriptive enough. We might
> someday (if we don't already) have a number of aggregates that produce
> an output that is a string; we can't name them all by the output type.

True, but the same point could be made against array_agg, and that
didn't stop the committee from choosing that name. As long as
string_agg is the "most obvious" aggregate-to-string functionality,
which ISTM it is, I think it's all right for it to have pride of place
in naming.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Pavel Stehule on
with actualised oids

Regards
Pavel Stehule

2010/1/26 David E. Wheeler <david(a)kineticode.com>:
> On Jan 25, 2010, at 6:56 AM, Pavel Stehule wrote:
>
>> actualised patch - the name is string_agg
>
> All looks fine except I'm getting this error during initdb:
>
> creating template1 database in /usr/local/pgsql-devel/data/base/1 ... FATAL:  could not create unique index "pg_proc_oid_index"
> DETAIL:  Key (oid)=(3031) is duplicated.
> child process exited with exit code 1
>
> Would you mind re-submitting with unique OIDs?
>
> Thanks,
>
> David
From: Robert Haas on
On Tue, Jan 26, 2010 at 1:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>>> But what it *produces* is a string.  For comparison, the
>>> SQL-standard-specified array_agg produces arrays, but what it
>>> acts on isn't an array.
>
>> This point is well-taken, but naming it string_agg() because it
>> produces a string doesn't seem quite descriptive enough.  We might
>> someday (if we don't already) have a number of aggregates that produce
>> an output that is a string; we can't name them all by the output type.
>
> True, but the same point could be made against array_agg, and that
> didn't stop the committee from choosing that name.  As long as
> string_agg is the "most obvious" aggregate-to-string functionality,
> which ISTM it is, I think it's all right for it to have pride of place
> in naming.

Maybe so, but personally, I'd still prefer something more descriptive.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers