From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "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 08:59:11 |
Message-ID: | 20100128175911.9791.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2010/1/28 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> > 2010/1/28 David E. Wheeler <david(at)kineticode(dot)com>:
> >> On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
> >>
> >>> * I think we cannot cache the delimiter at the first call.
> >>> For example,
> >>> SELECT string_agg(elem, delim)
> >>> FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
> >>> should return 'A+B*C' rather than 'A,B,C'.
> >
> > no, has not.
> What is use case for this behave??
I also think this usage is nonsense, but seems to be the most consistent
behavior for me. I didn't say anything about use-cases, but just capability.
Since we allow such kinds of usage for now, you need to verify the
delimiter is not changed rather than ignoring it if you want disallow
to change the delimiter during an aggregation.
Of course you can cache the first delimiter at start, and check delimiters
are not changed every calls -- but I think it is just a waste of cpu cycle.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Bunce | 2010-01-28 09:01:49 | Re: Add on_perl_init and proper destruction to plperl [PATCH] |
Previous Message | Guillaume Lelarge | 2010-01-28 08:47:46 | Re: Patch: libpq new connect function (PQconnectParams) |