Re: Review: listagg aggregate - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Review: listagg aggregate
Date
Msg-id e08cc0401001280908j5d7596fas3500d85161b78605@mail.gmail.com
Whole thread Raw
In response to Re: Review: listagg aggregate  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Review: listagg aggregate  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Review: listagg aggregate  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2010/1/29 Pavel Stehule <pavel.stehule@gmail.com>:
> 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.

What about get_fn_expr_arg_stable() to check if the argument is stable
during aggregate?

Regards,


--
Hitoshi Harada


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl [PATCH]
Next
From: Robert Haas
Date:
Subject: Re: Streaming replication, and walsender during recovery