Re: multiset patch review
От | Itagaki Takahiro |
---|---|
Тема | Re: multiset patch review |
Дата | |
Msg-id | AANLkTi==t6mc3QxHfrhaSZC3Z+=+oZztO05sdL+uvcQJ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: multiset patch review (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: multiset patch review
|
Список | pgsql-hackers |
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. Sure. I'll remove collect() function. I can also remove syntax support, but it requires rework for documentation (for, IS A SET operator to is_a_set function), so I'd like to wait for the final consensus a bit more. > 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. > Also the docs don't > say how it decides how many elements to remove, or what happens to a > multi-dimensional array. I wrote the description below in the patch: + In <function>array_sort</>, <function>set</>, and <function>trim_array</> + functions, input arrays are always flattened into one-dimensional arrays. + In addition, the lower bounds of the arrays are adjusted to 1. I'm not sure what is the consistent behavior for MD arrays. For example, array_concat() is very strict, but <@ and && operators don't care about the dimensions. I interpreted the second argument for trim_array() as a number of "elements", but of course we can redefine it as a number of "rows" for MD arrays. -- Itagaki Takahiro
В списке pgsql-hackers по дате отправления: