Re: multiset patch review

On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Mon, Jan 31, 2011 at 02:34, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> 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.
>>>
>>> +1 ... if we're going to provide nonstandard behavior, it should be with
>>> a different syntax.  Also, with a contrib module we could keep on
>>> providing the nonstandard behavior for people who still need it, even
>>> after implementing the standard properly.
>>
>> Good point.
>
> I agree for collect() function, that is the only function we cannot
> provide compatibility when we have MULTISET. But others are still
> reasonable because they won't provide nonstandard behavior.
>
> The SQL standard seems to have abstract COLLECTION data type as a
> super class of ARRAY and MULTISET. So, it's reasonable that
> functions and operators that accept MULTISETs also accept ARRAYs.
> For example, we will have cardinality(ARRAY) even if we have
> cardinality(MULTISET). Also, trim_array() is in the SQL standard.
>
> I can remove some parts in the patch, especially for parser changes,
> but others should be still in the core.

Well, do you want to revise this and submit a stripped-down version?
I'm not averse to adding things that are required by the standard and
won't cause backward compatibility problems later.

The documentation for trim_array() in the current patch version is
pretty terrible. The documentation describes it

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company