Re: multiset patch review

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: multiset patch review
Дата
Msg-id AANLkTinXNEWcPnwfauAt6QPPCQmQeUp4Jz2R4AxR2q7x@mail.gmail.com
обсуждение исходный текст
Ответ на Re: multiset patch review  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Ответы Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jan 31, 2011 at 04:34, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> 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.

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.

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

Fixed and add an example for a MD array.

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

Now it removes supplied number of slices at the end of array.
  trim_array( ARRAY[[1,2],[3,4]], 1) ==> ARRAY[[1,2]]
Also, it keep lower-bounds of the input array, that is an advantage
over slice syntax. Slice syntax always reset lower-bounds to 1.

--
Itagaki Takahiro

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Spread checkpoint sync
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Change pg_last_xlog_receive_location not to move backwards