Re: multiset patch review - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: multiset patch review
Date
Msg-id AANLkTi==t6mc3QxHfrhaSZC3Z+=+oZztO05sdL+uvcQJ@mail.gmail.com
Whole thread Raw
In response to Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: multiset patch review  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
List pgsql-hackers
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.

Sure. I'll remove collect() function. I can also remove syntax support,
but it requires rework for documentation (for, IS A SET operator to
is_a_set function), so I'd like to wait for the final consensus a bit more.

> 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.

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

I wrote the description below in the patch:
+     In <function>array_sort</>, <function>set</>, and <function>trim_array</>
+     functions, input arrays are always flattened into one-dimensional arrays.
+     In addition, the lower bounds of the arrays are adjusted to 1.

I'm not sure what is the consistent behavior for MD arrays. For example,
array_concat() is very strict, but <@ and && operators don't care about
the dimensions. I interpreted the second argument for trim_array() as
a number of "elements", but of course we can redefine it as a number of
"rows" for MD arrays.

--
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Per-column collation, the finale
Next
From: Robert Haas
Date:
Subject: Re: review: FDW API