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 по дате отправления: