Re: multiset patch review - Mailing list pgsql-hackers

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

I removed collect() aggregate function because the result type is MULTISET
in the spec. I keep all of other functions and operators because they won't
break anything in the standard. When we will have true MULTISET data type,
we can overload those functions and operators for MULTISET and ARRAY.

>> The documentation for trim_array() in the current patch version is
>> pretty terrible.  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.
>
> Oops, it's just my mistake. trim(anyarray, integer) is correct.

Fixed and add an example for a MD array.

>> Also the docs don't
>> say how it decides how many elements to remove, or what happens to a
>> multi-dimensional array.

Now it removes supplied number of slices at the end of array.
  trim_array( ARRAY[[1,2],[3,4]], 1) ==> ARRAY[[1,2]]
Also, it keep lower-bounds of the input array, that is an advantage
over slice syntax. Slice syntax always reset lower-bounds to 1.

--
Itagaki Takahiro

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Spread checkpoint sync
Next
From: Fujii Masao
Date:
Subject: Re: Change pg_last_xlog_receive_location not to move backwards