Skip site navigation (1) Skip section navigation (2)

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-31 06:49:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jan 31, 2011 at 04:34, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Mon, Jan 31, 2011 at 04:12, Robert Haas <robertmhaas(at)gmail(dot)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: multiset-20110131.patch
Description: application/octet-stream (62.1 KB)

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2011-01-31 07:12:21
Subject: Re: Change pg_last_xlog_receive_location not to move backwards
Previous:From: Robert HaasDate: 2011-01-31 04:41:36
Subject: Re: Spread checkpoint sync

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group