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  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI performance
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: arrays as pl/perl input arguments [PATCH]