Re: string_agg delimiter having no effect with order by
От | Pavel Stehule |
---|---|
Тема | Re: string_agg delimiter having no effect with order by |
Дата | |
Msg-id | AANLkTindCsN40_GAFpKkZLqEfzWB9fU58WHgh+GMMvA5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: string_agg delimiter having no effect with order by (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: string_agg delimiter having no effect with order by
Re: string_agg delimiter having no effect with order by |
Список | pgsql-bugs |
2010/8/5 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >>>>> The same problem can be with custom aggregates :( so this syntax isn't >>>>> too robust. > > BTW, I'm really not worried about that case. =C2=A0By the time someone is > advanced enough to have written their own multi-argument aggregate > definitions, they'll have absorbed the idea that the ORDER BY goes at > the end. =C2=A0What we need to accomplish here is just to not set traps at > the feet of novices using the feature for the first time. =C2=A0Which is > why I think it's sufficient to have a policy of not having built-in > aggregates that conflict in this way; I'm not proposing that we restrict > or discourage custom aggregates with optional arguments. > +1 but still when we remove one parametric string_agg, then this issue will not be documented. Pavel > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0regards, tom lane >
В списке pgsql-bugs по дате отправления: