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

From Pavel Stehule
Subject Re: Review: listagg aggregate
Date
Msg-id 162867791001280917k55f4637eub1c0f5eb9db06708@mail.gmail.com
Whole thread Raw
In response to Re: Review: listagg aggregate  (Hitoshi Harada <umi.tanuki@gmail.com>)
Responses Re: Review: listagg aggregate  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
List pgsql-hackers
2010/1/28 Hitoshi Harada <umi.tanuki@gmail.com>:
> 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?

I newer know so this function exists. Now we can

a) check and allow only stable params
b) when second parameter is stable, then store it and use it as constant.

I prefer a)

Pavel

>
> Regards,
>
>
> --
> Hitoshi Harada
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Review: listagg aggregate
Next
From: Tom Lane
Date:
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl [PATCH]