2010/8/4 Kevin Grittner <Kevin.Grittner@wicourts.gov>:
> Alex Hunsaker <badalex@gmail.com> wrote:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that
>>> this confusion is a sufficient reason to drop the one-argument
>>> form of string_agg. =C2=A0It's too late now though.
>>
The same problem can be with custom aggregates :( so this syntax isn't
too robust. We can support Oracle's syntax in future releases, where
syntax divide aggregate call and ORDER BY clause.
>> FWIW I think we can still change it. =C2=A0 Isn't this type of issue
>> part of what beta is for? =C2=A0If we were in RC that would be a
>> different story
>
> I like to think I'm pretty serious about controlling scope creep to
> prevent a release dragging out, but this one seems like beta testing
> uncovered a flaw in new code for the release. =C2=A0In my book, that
> makes it fair game to balance the risk of breaking things by
> changing it now against the problems we'll have long term if we
> leave it alone. =C2=A0I'm not sure if that was the basis of saying it was
> too late, or some other consideration.
It is just removing some from one perspective problematic code. This
doesn't add any feature - so it cannot be a precedents.
we can look on this situation from two views:
a) it is good, because we can document this feature/behave - without
one param aggregates people will repeat same situation with custom
aggregates- and this will not be documented.
b) it is bad, because lot of users will be confused.
I prefer @a
Regards
Pavel
>
> -Kevin
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>