From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(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 19:12:12 |
Message-ID: | AANLkTinwBGGSko9dDBKcu9Ot46da0niCAxNz=fK0AT3W@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 30, 2011 at 2:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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
Argh, sorry.
The documentation describe it as having the prototype
trim_array(anyarray), but it's called in the example as
trim(integer[], integer) - two arguments vs. one. Also the docs don't
say how it decides how many elements to remove, or what happens to a
multi-dimensional array.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-01-30 19:22:02 | Re: Include WAL in base backup |
Previous Message | Robert Haas | 2011-01-30 19:11:01 | Re: multiset patch review |