From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vladimir Svedov <vodevsh(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: array_ndims never returns zero |
Date: | 2017-12-29 16:52:33 |
Message-ID: | 23275.1514566353@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vladimir Svedov <vodevsh(at)gmail(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jack Christensen | 2017-12-29 16:55:25 | Re: Possible hole in Windows directory restrictions? |
Previous Message | Tom Lane | 2017-12-29 16:43:07 | Re: plpgsql function startup-time improvements |