Re: [HACKERS] Ongoing issues with representation of empty arrays

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):>> ...>> I plan to fix this one properly, unless
anyonehas 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
muchless clear what to do about this one. Thoughts? 
 
Tom> My instinct is to be conservative in what you send and liberal inTom> what you accept.  In this context that would
probablymean fixingTom> aclitem-related functions to accept both 0-dimensional andTom> 1-dimensional-0-length
inputs.Tom>(Actually, is there a reason to be picky about the inputTom> dimensionality at all, rather than just
iteratingover whateverTom> 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)