[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On 04/08/2013 07:16 PM, Brendan Jurd wrote: On 9 April 2013 09:24, Josh Berkus j...@agliodbs.com wrote: As much as I have a keen interest in this feature, it isn't (AFAIK) being considered for 9.3. Given that it's generated a fair amount of controversy, could we table it until 9.3 beta? There's still plenty of unresolved 9.3 patches in the queue. No problem. I certainly wasn't expecting it to run for 90 messages when I started out. I'll pipe down for now and resume after the beta. What's the status on this patch and current approach to ZDA? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On 12 June 2013 04:43, Josh Berkus j...@agliodbs.com wrote: What's the status on this patch and current approach to ZDA? Alright, it might be a good idea to have a quick recap. Last time, on Arrays Of Our Lives ... So I proposed and posted a patch aimed at deprecating zero-D arrays, and replacing them with 1-D empty arrays. That kicked off a long discussion, with some folks (Robert, Merlin, Florian et al) vigorously opposing any change in the behaviour of the array_(length|ndims|lower|upper) functions. To those folks, the behaviour would have to be a lot worse than it currently is to justify breaking compatibility with existing applications. The idea of using a GUC to smooth over the compatibility break was suggested, and firmly rejected. The idea of creating an entirely new type with nicer behaviours came up, but that wouldn't really fly because arrays have already hogged all the best syntax. Since compatibility breakage is so contentious, I suggested that we forget about changing the array representation and just add new functions with more sensible behaviours: * cardinality(anyarray) to return the length of the first dimension, zero if empty, and * array_num_items(anyarray) to return the total number of element positions per ArrayGetNItems, zero if empty. There have been attempts to add a cardinality function in the past, as it is required by the SQL spec, but these attempts have stalled when trying to decide how it should handle multidim arrays. Having it return the length of the first dimension is the more spec-compatible way to go, but some folks argued that it should work as ArrayGetNItems, because we don't already have a function for that at the SQL level. Therefore I propose we add cardinality() per the spec, and another function to expose ArrayGetNItems. And that's about where we got to, when the whole discussion was put on a time-out to make room for the beta. I am withdrawing the original zero-D patch in favour of the proposed new functions. If you have an opinion about that, please do chime in. Depending on how that goes I may post a patch implementing my new proposal in the next few days. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On Thu, Apr 4, 2013 at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote: The only reasonable answer for this (a provably used, non-security, non-standards violating, non-gross functionality breakage case) is *zero*. Our historically cavalier attitude towards compatibility breakage has been an immense disservice to our users and encourages very bad upgrade habits and is, IMNSHO, embarrassing. The flip side of this is that the ability to make improvements freely is one of the biggest strengths of free software over commercial software. Oracle and Microsoft invest *tons* of money in maintaining huge libraries of backward compatibility code and drastically limits their ability to keep making improvements. -- greg
[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
All, As much as I have a keen interest in this feature, it isn't (AFAIK) being considered for 9.3. Given that it's generated a fair amount of controversy, could we table it until 9.3 beta? There's still plenty of unresolved 9.3 patches in the queue. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On Mon, Apr 8, 2013 at 04:24:31PM -0700, Josh Berkus wrote: All, As much as I have a keen interest in this feature, it isn't (AFAIK) being considered for 9.3. Given that it's generated a fair amount of controversy, could we table it until 9.3 beta? There's still plenty of unresolved 9.3 patches in the queue. Can someone add a TODO item or a link to the thread? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On 9 April 2013 09:24, Josh Berkus j...@agliodbs.com wrote: As much as I have a keen interest in this feature, it isn't (AFAIK) being considered for 9.3. Given that it's generated a fair amount of controversy, could we table it until 9.3 beta? There's still plenty of unresolved 9.3 patches in the queue. No problem. I certainly wasn't expecting it to run for 90 messages when I started out. I'll pipe down for now and resume after the beta. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On Mon, Mar 25, 2013 at 5:14 PM, Josh Berkus j...@agliodbs.com wrote: Tom, No, it *isn't* a good idea. GUCs that change application-visible semantics are dangerous. We should have learned this lesson by now. Really? I thought that standard_conforming_strings was a great example of how to ease our users into a backwards-compatibility break. It is, but it was made in full knowledge of the risks and costs. What do you do if you're given two modules that have opposite expectations for this variable? One module or the other might have hidden unexpected bugs or even security holes if the variable is set in a way it doesn't expect. You have to pick one value for the whole database. I'm not as sanguine as Tom is about how likely these corner cases will be met actually. As far as I can tell checking IS NULL on array_length() was the supported way to check for 0-length arrays previously so I suspect a lot of applications will need to be updated. But it's not a hard update to do and is the kind of update that's often needed on major database upgrades. At least if it's a clean break then everyone on 9.3 knows they need to do IS NULL and everyone on 9.4 knows they need to check for 0. If there's a GUC then people need to code defensively without knowing which semantics they'll get. And if they test they need to test twice under both settings just in case the user's database has the other setting. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: Should array_length() Return NULL)
On 26 March 2013 05:26, Greg Stark st...@mit.edu wrote: I'm not as sanguine as Tom is about how likely these corner cases will be met actually. As far as I can tell checking IS NULL on array_length() was the supported way to check for 0-length arrays previously Correct. There was no other way to check for empty arrays, because every empty array was zero-D, and zero-D returns NULL from all array interrogation functions, even array_ndims (which is totally bonkers). At least if it's a clean break then everyone on 9.3 knows they need to do IS NULL and everyone on 9.4 knows they need to check for 0. And, as I pointed out in at the top of the thread, you can write coalesce(array_length(a,1), 0) = 0 if you want to be confident your code will continue work in either case, and for some folks I expect that will be the least painful way to upgrade from 9.3 - 9.4. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
