Re: multiset patch review - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: multiset patch review
Date
Msg-id AANLkTimj6WQeR+Vbop_nVG8nQd_m1hAyVUv0OdPCSgTq@mail.gmail.com
Whole thread Raw
In response to Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Jan 31, 2011 at 02:34, Robert Haas <robertmhaas@gmail.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.

--
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Joachim Wieland
Date:
Subject: Re: Snapshot synchronization, again...
Next
From: Heikki Linnakangas
Date:
Subject: Re: REVIEW: Determining client_encoding from client locale