Re: multiset patch review
От | Robert Haas |
---|---|
Тема | Re: multiset patch review |
Дата | |
Msg-id | AANLkTinzoU78_rp7hYD1Q87Z_g9As6iGs_OQ69f4_Ejd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: multiset patch review (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Ответы |
Re: multiset patch review
|
Список | 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 по дате отправления: