Re: string_agg delimiter having no effect with order by

On 5 August 2010 16:31, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2010/8/5 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.  By 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.  What we need to accomplish here is just to not set traps at
>> the feet of novices using the feature for the first time.  Which 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 ] )

--
Thom Brown
Registered Linux user: #516935