Maybe if you decide not to touch the code, I should report to documentation mail group, asking to add this special exception to docs?..
Thank you On 29 December 2017 at 19:50, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2017-12-29 17:52 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > >> Vladimir Svedov <vode...@gmail.com> writes: >> > Reading >> > https://stackoverflow.com/questions/48022753/why-does-array- >> ndimsarray-produce-null#48022980 >> > confused me much - why array_ndims never returns zero indeed?.. >> >> Yeah, it's not a very good choice that it returns null for a zero-D >> array. But it's been like that for 20-some years, so the question >> is whether we are prepared to take the compatibility hit from >> changing it. >> >> If we were willing to break things around zero-D arrays, I don't think >> that's the only thing to change. It's equally silly that array_dims() >> returns NULL for such arrays, for instance; their dimensions are >> certainly not unknown. Perhaps an empty string is the right result, >> though I've not thought about it hard. >> >> I'd also argue that an out-of-range AARR_NDIM result is grounds >> for raising an error; returning NULL is a poor substitute for >> reporting data corruption. >> >> In short, if we're to touch this, I'd want somebody to go through all >> the array functions/operators and see if anything else is weird with >> zero-D arrays. >> > > Although I see a cost of compatibility break, I agree so NULL in this case > is confusing. > > The empty array can be taken as possible unlimited dimensional with zero > sized dimensions. > > The test on zero is more readable. > > Regards > > Pavel > >> >> regards, tom lane >> >> >
