From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thom Brown <thom(at)linux(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alex Hunsaker <badalex(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: string_agg delimiter having no effect with order by |
Date: | 2010-08-05 15:31:10 |
Message-ID: | AANLkTindCsN40_GAFpKkZLqEfzWB9fU58WHgh+GMMvA5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2010-08-05 15:40:58 | Re: string_agg delimiter having no effect with order by |
Previous Message | Alex Hunsaker | 2010-08-05 15:26:47 | Re: BUG #5601: cannot create language plperl; |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-08-05 15:35:08 | Re: MERGE Specification |
Previous Message | Pavel Stehule | 2010-08-05 15:29:29 | Re: GROUPING SETS revisited |