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

Re: Review: listagg aggregate

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: listagg aggregate
Date: 2010-01-28 15:32:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/1/28 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> simplest could not be a best. There have to be only a const
>> expression. But we have not possibility to check it in pg.
> Well... that's an entirely arbitrary limitation.  I admit that it
> doesn't seem likely that someone would want to have a variable
> delimiter, but putting extra effort and code complexity into
> preventing it seems pointless.

It is only a few lines with zero complexity.

The main issue of Takahiro proposal is  "unclean" behave.

we can have a content

c1    c2
c11, c12,
c21, c22

and result of string_agg(c1, c2)

have to be ?? c11 c12 c21 or c11 c22 c21 ?? What if some content of c2
will be NULL ?? I checked oracle. Oracle doesn't allow variable as
delimiter. We can't check it. But we can fix first value and using it
as constant.

More - Takahiro proposal has one performance gain. It have to deTOAST
separator value in every cycle.

Takahiro has true - we can store length of separator and we can add
separator to cumulative value as binary value.

I prefer original behave with  note in documentation - so as separator
is used a value on first row, when is used expression and not


> ...Robert

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-28 15:34:19
Subject: Re: Review: Typed Table
Previous:From: Tom LaneDate: 2010-01-28 15:31:34
Subject: Re: Largeobject Access Controls (r2460)

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