On Sun, Jan 30, 2011 at 2:11 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro > <itagaki.takah...@gmail.com> wrote: >> On Mon, Jan 31, 2011 at 02:34, Robert Haas <robertmh...@gmail.com> wrote: >>>>> I'm in favor of rejecting this patch in its entirety. The >>>>> functionality looks useful, but once you remove the syntax support, it >>>>> could just as easily be distributed as a contrib module rather than in >>>>> core. >>>> >>>> +1 ... if we're going to provide nonstandard behavior, it should be with >>>> a different syntax. Also, with a contrib module we could keep on >>>> providing the nonstandard behavior for people who still need it, even >>>> after implementing the standard properly. >>> >>> Good point. >> >> I agree for collect() function, that is the only function we cannot >> provide compatibility when we have MULTISET. But others are still >> reasonable because they won't provide nonstandard behavior. >> >> The SQL standard seems to have abstract COLLECTION data type as a >> super class of ARRAY and MULTISET. So, it's reasonable that >> functions and operators that accept MULTISETs also accept ARRAYs. >> For example, we will have cardinality(ARRAY) even if we have >> cardinality(MULTISET). Also, trim_array() is in the SQL standard. >> >> I can remove some parts in the patch, especially for parser changes, >> but others should be still in the core. > > 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. > > The documentation for trim_array() in the current patch version is > pretty terrible. The documentation describes it
Argh, sorry. 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. Also the docs don't say how it decides how many elements to remove, or what happens to a multi-dimensional array. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
