On Mon, Jan 31, 2011 at 04:34, Itagaki Takahiro
> 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.
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2011-01-31 07:12:21|
|Subject: Re: Change pg_last_xlog_receive_location not to move backwards|
|Previous:||From: Robert Haas||Date: 2011-01-31 04:41:36|
|Subject: Re: Spread checkpoint sync|