On Mon, Jan 31, 2011 at 04:12, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
