Re: multiset patch review

2011/1/30 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro
> <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
>> On Mon, Jan 24, 2011 at 20:49, Robert Haas <robertmhaas(at)gmail(dot)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
>