2011/1/30 Robert Haas <robertmh...@gmail.com>: > On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro > <itagaki.takah...@gmail.com> wrote: >> On Mon, Jan 24, 2011 at 20:49, Robert Haas <robertmh...@gmail.com> wrote: >>> I notice that this is adding keywords and syntax support for what is >>> basically a PostgreSQL extension (since we certainly can't possibly be >>> following the SQL standards given that we're not implementing a new >>> datatype. Is that really a good idea? >> >> As I wrote here, >> http://archives.postgresql.org/pgsql-hackers/2011-01/msg00829.php >> I think we can follow the SQL standard incrementally because we >> have function overloads. >> >> One exception is the result type of collect() aggregate function. >> It returns an array for now, but will return a multiset when we >> support true multiset data type. > > So, the plan is to add this now with non-standard semantics and then > change the semantics later if and when we implement what the standard > requires? That's not something we usually do, and I don't see why > it's a better idea in this case than it is in general. It's OK to > have non-standard behavior with non-standard syntax, but I think > non-standard behavior with standard syntax is something we want to try > hard to avoid. > > I'm in favor of rejecting this patch in its entirety. The > functionality looks useful, but once you remove the syntax support, it > could just as easily be distributed as a contrib module rather than in > core.
Hello It must not be a significant problem with compatibility, because implemented operators and functions are implemented for arrays. Functions from this patch are very useful - there are lot of implementations in SQL language, and this implementation means a significant speed. I can't to believe so there can be situation, when pg will has a true support of collection and operations with arrays will not offer similar functionality. I propose a remove collect() aggregate, but all others functions and operators can stay. And if this isn't acceptable for Robert, then I like implementation of these functions without parser's changes as minimum. Function like array_sort, array_distinct and some variants array_union are really missing (should be in core). Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
