Re: array_ndims never returns zero - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: array_ndims never returns zero
Date
Msg-id CAFj8pRCiJwJMZcHJTJFXsNwDZS4JNvza5_zpxsxWOaj+zy3SPA@mail.gmail.com
Whole thread Raw
In response to Re: array_ndims never returns zero  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: array_ndims never returns zero  (Vladimir Svedov <vodevsh@gmail.com>)
List pgsql-hackers


2017-12-29 17:52 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Vladimir Svedov <vodevsh@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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Converting plpgsql to use DTYPE_REC for named composite types
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table