Re: Review: listagg aggregate

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Review: listagg aggregate
Дата
Msg-id 162867791001280732w70ec68f5obc7916f16313ab4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Review: listagg aggregate  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Review: listagg aggregate
Список pgsql-hackers
2010/1/28 Robert Haas <robertmhaas@gmail.com>:
> On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule <pavel.stehule@gmail.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
constant.

Regards
Pavel




>
> ...Robert
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Largeobject Access Controls (r2460)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Review: Typed Table