On 5 August 2010 16:31, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2010/8/5 Tom Lane <t...@sss.pgh.pa.us>: >> Pavel Stehule <pavel.steh...@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. 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
