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