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