Re: multiset patch review - Mailing list pgsql-hackers

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

I am still not in favor of adding this syntax.  I'd be in favor of
adding array_cardinality(), trim_array(), array_sort(), and
array_flatten().  [It sure is awkward that trim_array has the word
array second and all of our other array functions have it first - is
this required by the spec?]

array_to_set() and array_is_set() seem possibly useful, but I probably
would have called them array_remove_dups() and array_has_dups().  I
might be in the minority on that one, though.

I think array_subset(), array_union(), array_intersect(), and
array_except() are useful, but I think they should just be regular
functions, without any special syntax.

fusion() and intersection() also seem useful, but maybe it would be
more consistent to all them array_fusion() and array_intersection().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SSI performance
Next
From: Andrew Dunstan
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]