>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730): >> ... >> I plan to fix this one properly, unless anyone has any objections. Tom> Just to clarify, what do you think is "properly"? I would say, that any time an intarray function returns an empty result it should be the standard 0-dimensional representation that every other array operation uses. The intarray functions all seem already able to take such values as inputs. Also there should be regression tests for this (none of intarray's existing tests have any empty arrays at all). >> Second is aclitem[], past bug #8395 which was not really resolved; empty >> ACLs are actually 1-dim arrays of length 0, and all the ACL functions >> insist on that, which means that you can't call aclexplode('{}') for >> example: >> It's much less clear what to do about this one. Thoughts? Tom> My instinct is to be conservative in what you send and liberal in Tom> what you accept. In this context that would probably mean fixing Tom> aclitem-related functions to accept both 0-dimensional and Tom> 1-dimensional-0-length inputs. Tom> (Actually, is there a reason to be picky about the input Tom> dimensionality at all, rather than just iterating over whatever Tom> the array contents are?) Currently there is this: #define ACL_NUM(ACL) (ARR_DIMS(ACL)[0]) which is obviously wrong for dimensions other than exactly 1. I don't _think_ there's any great obstacle to fixing this; the only code that would care about number of dimensions would be allocacl, and since there'd be no obvious reason to preserve the shape of an aclitem[] anywhere, that could just do 0 or 1 dimensions. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers