Re: multiset patch review

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: multiset patch review
Date: 2011-01-30 18:46:15
Message-ID: AANLkTimj6WQeR+Vbop_nVG8nQd_m1hAyVUv0OdPCSgTq@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Itagaki Takahiro

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-01-30 18:56:06 Re: REVIEW: Determining client_encoding from client locale
Previous Message Joachim Wieland 2011-01-30 17:36:12 Re: Snapshot synchronization, again...