Re: string_agg delimiter having no effect with order by - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: string_agg delimiter having no effect with order by
Date
Msg-id AANLkTindCsN40_GAFpKkZLqEfzWB9fU58WHgh+GMMvA5@mail.gmail.com
Whole thread Raw
In response to Re: string_agg delimiter having no effect with order by  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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  (Thom Brown <thom@linux.com>)
List 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 by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: BUG #5601: cannot create language plperl;
Next
From: Tom Lane
Date:
Subject: Re: string_agg delimiter having no effect with order by