Re: string_agg delimiter having no effect with order by

On 5 August 2010 16:31, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 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. =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. =A0What we need to accomplish here is just to not set traps at
>> the feet of novices using the feature for the first time. =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
>

I think the problem is people like me not reading this important
information:http://www.postgresql.org/docs/9.0/static/sql-expressions.html#=
SYNTAX-AGGREGATES

It's clear as day upon reading that.  It's a case of one page reading:

string_agg(expression [, delimiter ] )

and another reading:

aggregate_name (expression [ , ... ] [ order_by_clause ] )

and you effectively end up with:

string_agg(expression [, delimiter ] [ order_by_clause ] )

--=20
Thom Brown
Registered Linux user: #516935