From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Date: | 2013-03-27 13:21:49 |
Message-ID: | CAEZATCU2-VNShBmrPbhk-MuVY8gq+4X+aYz88x6QjZYvLNRBWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 March 2013 20:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.
>
The patch is also allowing '{{},{},{}}' which is described up-thread
as a 2-D empty array. That's pretty misleading, since it has length 3
(in the first dimension). '{{},{}}' and '{{}}' are both "more empty",
but neither is completely empty. It feels as though, if you were going
down that road, then for completeness you'd need a new syntax for a
truly empty 2-D array, e.g., '{}^2', but I can't really think of a
use-case for that, or for any of the others for that matter.
You'd be making it possible to have multiple different 2-D arrays, all
empty in the sense of having no elements, but which would compare
differently. Pretty much all you would be able to do with such arrays
would be to append additional empty arrays.
> 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'm not saying that the current situation is not broken. I'm just
questioning whether the fix is actually any less confusing than what
we have now.
+1 for adding an array_is_empty() function though
--- I think there is enough evidence just in this thread that the
current API is confusing. We don't currently provide a definitive way
to test for empty arrays, so people inevitably invent their own (all
subtly different) solutions.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-03-27 13:28:05 | Re: [COMMITTERS] pgsql: Add PF_PRINTF_ATTRIBUTE to on_exit_msg_fmt. |
Previous Message | Robert Haas | 2013-03-27 13:21:33 | Re: [COMMITTERS] pgsql: Allow external recovery_config_directory |