From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(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-02-04 17:29:59 |
Message-ID: | AANLkTinzoU78_rp7hYD1Q87Z_g9As6iGs_OQ69f4_Ejd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 31, 2011 at 1:49 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PostgreSQL - Hans-Jürgen Schönig | 2011-02-04 17:48:23 | SELECT ... WHERE fti_query ORDER BY numeric_col LIMIT x - problem |
Previous Message | Kevin Grittner | 2011-02-04 17:29:15 | Re: SSI performance |