On 4/1/13 8:58 AM, Merlin Moncure wrote:
On Mon, Apr 1, 2013 at 6:43 AM, Robert Haas <robertmh...@gmail.com> wrote:
On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@gmail.com> writes:
Well, you could easily change array_ndims() to error out if ARR_NDIM()
is negative or more than MAXDIM and return NULL only if it's exactly
0. That wouldn't break backward compatibility because it would throw
an error only if fed a value that shouldn't ever exist in the first
place, short of a corrupted database. I imagine the other functions
are amenable to similar treatment.
I haven't looked at the patch in detail, but I thought one of the key
changes was that '{}' would now be interpreted as a zero-length 1-D
array rather than a zero-D array. If we do that it seems a bit moot
to argue about whether we should exactly preserve backwards-compatible
behavior in array_ndims(), because the input it's looking at won't be
the same anymore anyway.
In any case, the entire point of this proposal is that the current
behavior around zero-D arrays is *broken* and we don't want to be
backwards-compatible with it anymore. So if you wish to argue against
that opinion, do so; but it seems a bit beside the point to simply
complain that backwards compatibility is being lost.
I don't think the current behavior is broken. I found it
counterintuitive at first, but then I got used to it. It's reasonably
self-consistent: arrays can't have empty dimensions, therefore the
empty array is unique and dimensionless. Is that the behavior I would
have picked if I had designed the type? No, it isn't. I wouldn't
have tried to support one-dimensional arrays and multi-dimensional
arrays in the same data type either, nor would I have supported
non-default lower bounds. But all of those ships have sailed, and the
time to change them is not after people have spent 10 years building
applications that work with the current behavior. If we want to
introduce a new type with different, perhaps better, behavior, well, I
think that might be a fine idea. But I *don't* think imposing a hard
compatibility break on users of arrays is a good idea.
100% agree. Also huge +1 on your backwards compatibility comments
upthread -- couldn't agree more. My $company just wrapped up a one
year porting effort to 9.2 from *8.1* due to compatibility issues.
If you want custom array behaviors, creating a type is probably the
best way unless it can be 100% proven that this will not break code.
+1, and FWIW I'd love to see a new, cleaner array implementation. My beefs with
the current system:
- Adjustable lower bound is *way* more trouble than it's worth (does anyone
actually have a use-case for supporting it?)
- Need to be able to tell if an array is actually empty/null, which is not the
same as an array where all elements are null
- Enforced dimensions would be nice, though I can't say it's that big a deal
- Not sure that special casing 1 dimension arrays would be worth it... perhaps
enforced dimensions solve whatever problems exist there
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
