Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes: On 7 April 2013 01:43, Kevin Grittner kgri...@ymail.com wrote: Your interpretation matches mine all around. It is unfortunate that we have hijacked the standard's syntax for arrays to add a matrix feature. It really is unfortunate. I wonder if it was done in an attempt to mimic Oracle behaviour. Hardly likely. That code goes back to Berkeley days (PostQUEL) --- there is clear ancestry from the array code in Postgres v4r2 released June 1994. It's more or less a coincidence that it matches the SQL spec at all, and I'd be astonished if it matched Oracle particularly closely. On the specific issue of CARDINALITY, I guess we need to decide whether we are going to pretend that our array/matrix thing is actually nested. I first argued that we should not. But it occurred to me that if we do pretend, it would at least leave the door ajar if we want to do something to make our arrays more nest-like in future, without disrupting the behaviour of CARDINALITY. This seems to be exactly the same uncertainty that we couldn't resolve back in the 8.4 devel cycle, for exactly the same reasons. I don't see that the discussion has moved forward any :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 8 April 2013 16:09, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: On the specific issue of CARDINALITY, I guess we need to decide whether we are going to pretend that our array/matrix thing is actually nested. I first argued that we should not. But it occurred to me that if we do pretend, it would at least leave the door ajar if we want to do something to make our arrays more nest-like in future, without disrupting the behaviour of CARDINALITY. This seems to be exactly the same uncertainty that we couldn't resolve back in the 8.4 devel cycle, for exactly the same reasons. I don't see that the discussion has moved forward any :-( I had a poke around in the archives, and it seems to me that the major argument that was advanced in favour of making cardinality() return the total number of items was ... we don't have anything that does that yet. That's why I'm proposing we add array_num_items as well -- I do think there should be a function for this, I just don't think cardinality fits the bill. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 7 April 2013 01:43, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com wrote: Indeed it does not prohibit nesting arrays inside other arrays, but the multidim arrays that Postgres allows you to create are not the same thing as nested arrays. Your interpretation matches mine all around. It is unfortunate that we have hijacked the standard's syntax for arrays to add a matrix feature. It really is unfortunate. I wonder if it was done in an attempt to mimic Oracle behaviour. It seems to leave us without any way forward on these issues that I like very much. On the specific issue of CARDINALITY, I guess we need to decide whether we are going to pretend that our array/matrix thing is actually nested. I first argued that we should not. But it occurred to me that if we do pretend, it would at least leave the door ajar if we want to do something to make our arrays more nest-like in future, without disrupting the behaviour of CARDINALITY. It is unlikely that we ever would make such a change, but given the intensity of the opposition to any kind of SQL-level behavioural changes we've had on this thread, I don't want to create any more barriers to future efforts to comport with the spec. So how about: * we add CARDINALITY, make it work like array_length(a, 1) except that it returns zero for empty arrays, and * we add array_num_items, which exposes the internal ArrayGetNItems, and returns zero for empty arrays. As in: CARDINALITY(ARRAY[[1,2], [3,4], [5,6]]) = 3 array_num_items(ARRAY[[1,2], [3,4], [5,6]]) = 6 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 6 April 2013 01:59, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com wrote: The language specifically allows for zero elements, and does not contemplate multiple dimensions. I don't remember anything in the spec which would prohibit the data type of an array element from itself being an array, however. Indeed it does not prohibit nesting arrays inside other arrays, but the multidim arrays that Postgres allows you to create are not the same thing as nested arrays. I believe that a purely to-spec implementation would allow you to make an array-of-int-arrays, but since each element is its own separate collection there would be no requirement that they have the same cardinality as each other. For example, ARRAY[[1], [2,3], [4,5,6]] is a valid collection per the spec, but Postgres won't let you create this, because Postgres is trying to create a 2-D matrix of integers, rather than a collection of collections of integers. The inability to extend multidim arrays in Postgres is another manifestation of this matrix-oriented design. Extending nested collections is a no-brainer. Extending matrices while ensuring they remain perfectly regular ... not so much. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com wrote: On 6 April 2013 01:59, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com wrote: The language specifically allows for zero elements, and does not contemplate multiple dimensions. I don't remember anything in the spec which would prohibit the data type of an array element from itself being an array, however. Indeed it does not prohibit nesting arrays inside other arrays, but the multidim arrays that Postgres allows you to create are not the same thing as nested arrays. I believe that a purely to-spec implementation would allow you to make an array-of-int-arrays, but since each element is its own separate collection there would be no requirement that they have the same cardinality as each other. For example, ARRAY[[1], [2,3], [4,5,6]] is a valid collection per the spec, but Postgres won't let you create this, because Postgres is trying to create a 2-D matrix of integers, rather than a collection of collections of integers. The inability to extend multidim arrays in Postgres is another manifestation of this matrix-oriented design. Extending nested collections is a no-brainer. Extending matrices while ensuring they remain perfectly regular ... not so much. Your interpretation matches mine all around. It is unfortunate that we have hijacked the standard's syntax for arrays to add a matrix feature. It seems to leave us without any way forward on these issues that I like very much. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com wrote: The language specifically allows for zero elements, and does not contemplate multiple dimensions. I don't remember anything in the spec which would prohibit the data type of an array element from itself being an array, however. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
2013-04-03 20:58 keltezéssel, Gavin Flower írta: On 04/04/13 05:36, David E. Wheeler wrote: On Apr 3, 2013, at 9:30 AM, Tom Lanet...@sss.pgh.pa.us wrote: Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. I say we turn the default lower bound up to 11. David In keeping with the level of irrationality in this thread, maybe we should set it to an irrational number like the square root of 2, or transcend our selves and make in a transcendental number like pi! :-) I suppose using the square root of minus one would be consider too imaginative??? :-) Nah, that would make arrays have 2 dimensions as a minimum... :-) Cheers, Gavin -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Wed, Apr 3, 2013 at 11:11 PM, Tom Lane t...@sss.pgh.pa.us wrote: In any case, the whole exercise is pointless if we don't change the visible behavior of array_dims et al. So I think the idea that this would be without visible consequence is silly. What's up for argument is just how much incompatibility is acceptable. 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. Changing the way array_dims works for a minor functionality enhancement is gratuitous and should be done, if at all, via a loudly advertised deprecation/replacement cycle with a guarding GUC (yes, I hate them too, but not nearly as much as the expense of qualifying vast code bases against random compatibility breakages every release). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Thu, Apr 4, 2013 at 11:10 AM, 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*. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Robert Haas robertmh...@gmail.com writes: On Thu, Apr 4, 2013 at 11:10 AM, 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*. +1. Well, if we're going to take that hard a line on it, then we can't change anything about array data storage or the existing functions' behavior; which leaves us with either doing nothing at all, or inventing new functions that have saner behavior while leaving the old ones in place. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 5 April 2013 07:43, Tom Lane t...@sss.pgh.pa.us wrote: Well, if we're going to take that hard a line on it, then we can't change anything about array data storage or the existing functions' behavior; which leaves us with either doing nothing at all, or inventing new functions that have saner behavior while leaving the old ones in place. And then we are in the awkward position of trying to explain the differences in behaviour between the old and new functions ... presumably with a dash of for historical reasons and a sprinkling of to preserve compatibility in every other paragraph. The other suggestion that had been tossed around elsewhere upthread was inventing a new type that serves the demand for a straightforward mutable list, which has exactly one dimension, and which may be sensibly empty. Those few who are interested in dimensions = 2 could keep on using arrays, with all their backwards-compatible silliness intact, and everybody else could migrate to lists at their leisure. I don't hate the latter idea from a user perspective, but from a developer perspective I suspect there are valid objections to be made. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes: The other suggestion that had been tossed around elsewhere upthread was inventing a new type that serves the demand for a straightforward mutable list, which has exactly one dimension, and which may be sensibly empty. Those few who are interested in dimensions = 2 could keep on using arrays, with all their backwards-compatible silliness intact, and everybody else could migrate to lists at their leisure. I don't hate the latter idea from a user perspective, but from a developer perspective I suspect there are valid objections to be made. The real problem with that is that the existing arrays have glommed onto the syntax that is both most natural and SQL-spec-required. I don't think there is a lot of room to shove in a different kind of critter there. (There's been a remarkable lack of attention to the question of spec compliance in this thread, btw. Surely the standard has something to say on the matter of zero-length arrays?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 5 April 2013 13:04, Tom Lane t...@sss.pgh.pa.us wrote: (There's been a remarkable lack of attention to the question of spec compliance in this thread, btw. Surely the standard has something to say on the matter of zero-length arrays?) From 4.10 in my draft copy of Foundation, arrays are one of two collection types (the other being multisets), and: A collection is a composite value comprising zero or more elements, each a value of some data type DT The number of elements in C is the cardinality of C An array is a collection A in which each element is associated with exactly one ordinal position in A. If n is the cardinality of A, then the ordinal position p of an element is an integer in the range 1 (one) ≤ p ≤ n. The language specifically allows for zero elements, and does not contemplate multiple dimensions. The specification for the array constructor syntax (6.36) and array element reference by subscript (6.23) also make it fairly clear that only 1-D arrays were being considered. I'd say we've already gone way off-menu by having multidims. A more compliant approach would have been to implement arrays as 1-D only, and then maybe have a separate thing (matrices?) for multidims. While I was in there I noticed CARDINALITY, which would be pretty easy to add and would at least provide a more productive way to get the real length of an array without disrupting existing functionality: cardinality expression ::= CARDINALITY left paren collection value expression right paren 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes: On 5 April 2013 13:04, Tom Lane t...@sss.pgh.pa.us wrote: (There's been a remarkable lack of attention to the question of spec compliance in this thread, btw. Surely the standard has something to say on the matter of zero-length arrays?) The language specifically allows for zero elements, and does not contemplate multiple dimensions. The specification for the array constructor syntax (6.36) and array element reference by subscript (6.23) also make it fairly clear that only 1-D arrays were being considered. I'd say we've already gone way off-menu by having multidims. Yeah, we knew that. I don't have a problem with seeing multidim arrays as an extension to the standard though. The point is that the behavior for the 1-D, default-lower-bound case ought to match the standard. While I was in there I noticed CARDINALITY, which would be pretty easy to add and would at least provide a more productive way to get the real length of an array without disrupting existing functionality: Yeah, that would at least fix the null-result-for-empty-array problem for that particular functionality. Still, this is ammunition for the position that null results for empty arrays are just broken. BTW ... if you check the archives you will find that we had cardinality() for a short while, and removed it before 8.4 release, because we couldn't agree on what it ought to return when given a multi-dimensional array. I'm afraid that issue is still unresolved. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 5 April 2013 15:05, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: While I was in there I noticed CARDINALITY, which would be pretty easy to add and would at least provide a more productive way to get the real length of an array without disrupting existing functionality: Yeah, that would at least fix the null-result-for-empty-array problem for that particular functionality. Still, this is ammunition for the position that null results for empty arrays are just broken. BTW ... if you check the archives you will find that we had cardinality() for a short while, and removed it before 8.4 release, because we couldn't agree on what it ought to return when given a multi-dimensional array. I'm afraid that issue is still unresolved. Well for what it's worth I would expect cardinality() to return the total number of elements in the array (per ArrayGetNItems). It's consistent with the spec's identification of an array as a collection. You can chunk the elements into dimensions however you want, but it's still a collection of elements, and the cardinality is still the number of elements. The nesting interpretation doesn't accord with our internal representation, nor with our requirement that multidim arrays be regular, nor with the fact that we can't put an array of texts inside an array of ints. Our array input syntaxes for multidim arrays look nest-ish but what they produce is not nested. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Apr1, 2013, at 13:43 , Robert Haas robertmh...@gmail.com wrote: 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. +1. Especially since having infinitely many variants of empty is IMHO hardly an improvement over the existing situation. If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types… best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/02/2013 02:46 PM, Florian Pflug wrote: On Apr1, 2013, at 13:43 , Robert Haas robertmh...@gmail.com wrote: 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. +1. Especially since having infinitely many variants of empty is IMHO hardly an improvement over the existing situation. If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types… That would actually break a HUGE number of users, since the default lower bound is 1. I have seen any number of pieces if code that rely on that. Doesn't the standard have something to say about all this? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Apr3, 2013, at 15:30 , Andrew Dunstan and...@dunslane.net wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote: If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types… That would actually break a HUGE number of users, since the default lower bound is 1. I have seen any number of pieces if code that rely on that. Uh, yeah, we should make it 1 then, not 0, then. As long as the bound is fixed, conversion to native C/Java/Ruby/Python/... arrays would still be lossless. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Andrew Dunstan and...@dunslane.net writes:
On 04/02/2013 02:46 PM, Florian Pflug wrote:
If we're going to break compatibility, we should IMHO get rid of
non-zero lower bounds all together. My guess is that the number of
affected users wouldn't be much higher than for the proposed patch,
and it'd allow lossless mapping to most language's native array types
That would actually break a HUGE number of users, since the default
lower bound is 1. I have seen any number of pieces if code that rely on
that.
I assume he meant non-one lower bounds. But in any case, removing the
option for other lower bounds would be very clearly a removal of useful
functionality, so I don't see it happening ... certainly not if we're
so tied to bug-compatibility that we can't redefine the number of
dimensions an empty array has.
I think though that the upthread argument that we'd have multiple
interpretations of the same thing is bogus. To me, the core idea that's
being suggested here is that '{}' should mean a zero-length 1-D array,
not a zero-D array as formerly. We would still need a way to represent
zero-D arrays, if only because they'd still exist on-disk in existing
databases (assuming we're not willing to break pg_upgrade for this).
I suggest that that ought *not* involve any braces. Perhaps '[]=' would
be a suitable representation. In the other direction, ISTM that
'{{},{},{}}' is a zero-by-three array, entirely distinct from '{}' or
'{{}}' in dimensionality if not content. I haven't worked this out in
complete detail, but if different strings mean the same thing then we
don't have the representation defined right.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan and...@dunslane.net wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote: If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types… That would actually break a HUGE number of users, since the default lower bound is 1. I have seen any number of pieces if code that rely on that. Uh, yeah, we should make it 1 then, not 0, then. As long as the bound is fixed, conversion to native C/Java/Ruby/Python/... arrays would still be lossless. best regards, Florian Pflug Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. Maybe we should adopt the famous compromise of '0.5'? :-) Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
2013/4/3 Gavin Flower gavinflo...@archidevsys.co.nz On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan and...@dunslane.net wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote: If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types… That would actually break a HUGE number of users, since the default lower bound is 1. I have seen any number of pieces if code that rely on that. Uh, yeah, we should make it 1 then, not 0, then. As long as the bound is fixed, conversion to native C/Java/Ruby/Python/... arrays would still be lossless. best regards, Florian Pflug Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. pascal, ADA, and ALGOL like languages Regards Pavel Maybe we should adopt the famous compromise of '0.5'? :-) Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/**mailpref/pgsql-hackershttp://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 04:58, Pavel Stehule wrote: 2013/4/3 Gavin Flower gavinflo...@archidevsys.co.nz mailto:gavinflo...@archidevsys.co.nz On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan and...@dunslane.net mailto:and...@dunslane.net wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote: If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types... That would actually break a HUGE number of users, since the default lower bound is 1. I have seen any number of pieces if code that rely on that. Uh, yeah, we should make it 1 then, not 0, then. As long as the bound is fixed, conversion to native C/Java/Ruby/Python/... arrays would still be lossless. best regards, Florian Pflug Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. pascal, ADA, and ALGOL like languages Regards Pavel ALOGOL 60 was zero based by default, as I remember deliberately setting the lower bound to 1, I managed to avoid PASCAL and I only glanced at ADA. Cheers, Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
2013/4/3 Gavin Flower gavinflo...@archidevsys.co.nz On 04/04/13 04:58, Pavel Stehule wrote: 2013/4/3 Gavin Flower gavinflo...@archidevsys.co.nz On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan and...@dunslane.net wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote: If we're going to break compatibility, we should IMHO get rid of non-zero lower bounds all together. My guess is that the number of affected users wouldn't be much higher than for the proposed patch, and it'd allow lossless mapping to most language's native array types… That would actually break a HUGE number of users, since the default lower bound is 1. I have seen any number of pieces if code that rely on that. Uh, yeah, we should make it 1 then, not 0, then. As long as the bound is fixed, conversion to native C/Java/Ruby/Python/... arrays would still be lossless. best regards, Florian Pflug Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. pascal, ADA, and ALGOL like languages Regards Pavel ALOGOL 60 was zero based by default, as I remember deliberately setting the lower bound to 1, I managed to avoid PASCAL and I only glanced at ADA. http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29 Regards Pavel Cheers, Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Pavel ALOGOL 60 was zero based by default, as I remember deliberately setting the lower bound to 1, I managed to avoid PASCAL and I only glanced at ADA. http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29 In Pascal and similar languages (Wirth family) is possible to define lower bound - any value (like PL/pgSQL). Depends on a school - but lot of people used 1. I remember - it was one argument for in Pascal/C flame war. Regards Pavel Regards Pavel Cheers, Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Apr 3, 2013, at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. I say we turn the default lower bound up to 11. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/03/2013 11:34 AM, Gavin Flower wrote: Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. Pascal and Ada are obvious examples. I'm quite sure there are others, but don't have time to do the research. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Wed, Apr 3, 2013 at 12:36 PM, David E. Wheeler da...@kineticode.com wrote: On Apr 3, 2013, at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. I say we turn the default lower bound up to 11. +1. I think that's clearly a compromise position that will make everyone equally happy. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 3 April 2013 15:10, Tom Lane t...@sss.pgh.pa.us wrote:
I think though that the upthread argument that we'd have multiple
interpretations of the same thing is bogus. To me, the core idea that's
being suggested here is that '{}' should mean a zero-length 1-D array,
not a zero-D array as formerly. We would still need a way to represent
zero-D arrays, if only because they'd still exist on-disk in existing
databases (assuming we're not willing to break pg_upgrade for this).
I suggest that that ought *not* involve any braces. Perhaps '[]=' would
be a suitable representation.
Then restoring an old SQL dump would silently convert all old zero-D
arrays to zero-length 1-D arrays. Also, if you failed to completely
rewrite all your application code, and accidentally missed a few
functions, you could very easily end up in a situation where your
tables contained a mixture of zero-D arrays and zero-length 1-D
arrays, that wouldn't compare equally, leading to all sorts of nasty
bugs.
In the other direction, ISTM that
'{{},{},{}}' is a zero-by-three array,
Isn't that a three-by-zero array rather than a zero-by-three array?
Either way, what is the use-case for it? I certainly can't remember
ever using a 0x3 or 3x0 matrix.
entirely distinct from '{}' or
'{{}}' in dimensionality if not content.
And '{{}}' is a one-by-zero array. There is currently no proposed
syntax for representing a zero-by-zero array, or a zero-by-one array.
All I see here is endless opportunity for confusion and code breakage,
with very little real benefit.
I actually don't think the current behaviour is broken. I find it
perfectly logical and consistent to have a single dimensionless
concept of an empty array. It has no elements, so questions like are
they arranged in 1-D or 2-D, and what index do they start at are
meaningless, and so should return NULL. The only counter-intuitive
thing is that array_length() returns NULL instead of 0 for the empty
array, and it doesn't take long to get used to that behaviour.
Much of this seems to have grown out of a desire to fix the confusing
behaviour of array_length(), but seems to have ended up in a much more
confusing place.
Given that array_length() takes 2 arguments, it is somewhat forgivable
for it to return NULL when you ask for the array's length in a
dimension that it doesn't have. Perhaps what might make the API easier
to work with is a new single-argument function --- e.g., array_size()
that would return the number of elements in the array --- 0 for '{}',
3 for '{1,2,3}', 6 for '{{1,2},{3,4},{5,6}}' and so on.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Tom Lane t...@sss.pgh.pa.us wrote: Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. When I started programming the top four languages for business programming were COBOL, BASIC, RPG II, and assembly language. (Pascal and C came later, and I never saw much use of Fortran by anyone other than mathematicians.) Except for assembly language, the subscripts for arrays either started with 1 always, or that was the default. Given when it was first developed, it's not too surprising that the SQL standard adopted 1 as the first element of an array. Which is more natural depends on whether you think of the subscript in terms of ordinal positions or offsets from the base address. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 05:21, Pavel Stehule wrote: Pavel ALOGOL 60 was zero based by default, as I remember deliberately setting the lower bound to 1, I managed to avoid PASCAL and I only glanced at ADA. http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29 In Pascal and similar languages (Wirth family) is possible to define lower bound - any value (like PL/pgSQL). Depends on a school - but lot of people used 1. I remember - it was one argument for in Pascal/C flame war. Regards Pavel [...] At the time (just over 40 years ago!) I was adamant that arrays should start with an index of one, now I much prefer zero. Probably I prefer zero in part, because now I understand what is happening at the machine code level, and partly because zero is the default for the main languages I use. Wasting time on Google (I have 'more' important things I 'should' be doing!), I find ALGOL 60 did not appear to have a default value for the lower index - not only that, but one could make it negative! see: http://www.csci.csusb.edu/dick/samples/algol60.syntax.html Anyhow, I think we should standardise on zero as the initial index to be as consistent as practicable. However, not with a religious zeal at the expense of practical considerations! Cheers, Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 2013-04-04 07:42:36 +1300, Gavin Flower wrote: On 04/04/13 05:21, Pavel Stehule wrote: Pavel ALOGOL 60 was zero based by default, as I remember deliberately setting the lower bound to 1, I managed to avoid PASCAL and I only glanced at ADA. http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29 In Pascal and similar languages (Wirth family) is possible to define lower bound - any value (like PL/pgSQL). Depends on a school - but lot of people used 1. I remember - it was one argument for in Pascal/C flame war. Regards Pavel [...] At the time (just over 40 years ago!) I was adamant that arrays should start with an index of one, now I much prefer zero. Probably I prefer zero in part, because now I understand what is happening at the machine code level, and partly because zero is the default for the main languages I use. Wasting time on Google (I have 'more' important things I 'should' be doing!), I find ALGOL 60 did not appear to have a default value for the lower index - not only that, but one could make it negative! see: http://www.csci.csusb.edu/dick/samples/algol60.syntax.html Anyhow, I think we should standardise on zero as the initial index to be as consistent as practicable. However, not with a religious zeal at the expense of practical considerations! Changing this now, rather than on a green field, strikes me as a pretty absurd exercise in frustrating users by breaking queries subtly. Since 1 is a value index that won't always break visible. -1 Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 05:30, Tom Lane wrote: Zero as the default lower bound is consistent with most languages (especially the common ones like C, C++, Java, Python), in fact I don't remember any language where that is not the case (ignoring SQL) - and I've written programs in about 20 languages. Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. regards, tom lane I had forgotten the indexing in BASIC FORTRAN, I now recall COBOL's TABLE's were equivalent to arrays and they started at one. Cheers, Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Gavin Flower gavinflo...@archidevsys.co.nz wrote: Anyhow, I think we should standardise on zero as the initial index to be as consistent as practicable. If you want to suggest a default of zero for the first subscript of an array in SQL, please don't confuse the issue by using any form of the word standard in that proposal. There are ANSI and ISO standards for SQL, and they require that the first element of an array is one. I'm OK with *extending* the standard by *allowing* other values, but let's not flaunt the standard and break existing code by changing the *default*. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 05:36, David E. Wheeler wrote: On Apr 3, 2013, at 9:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Fortran ... Basic ... actually I'd have thought that zero was a minority position. Fashions change I guess. I say we turn the default lower bound up to 11. David In keeping with the level of irrationality in this thread, maybe we should set it to an irrational number like the square root of 2, or transcend our selves and make in a transcendental number like pi! :-) I suppose using the square root of minus one would be consider too imaginative??? :-) Cheers, Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 07:58, Kevin Grittner wrote: Gavin Flower gavinflo...@archidevsys.co.nz wrote: Anyhow, I think we should standardise on zero as the initial index to be as consistent as practicable. If you want to suggest a default of zero for the first subscript of an array in SQL, please don't confuse the issue by using any form of the word standard in that proposal. There are ANSI and ISO standards for SQL, and they require that the first element of an array is one. I'm OK with *extending* the standard by *allowing* other values, but let's not flaunt the standard and break existing code by changing the *default*. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company You omitted my rider 'However, not with a religious zeal at the expense of practical considerations!' Which was meant to cover concerns like yours. Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 2013-04-04 08:03:03 +1300, Gavin Flower wrote:
On 04/04/13 07:58, Kevin Grittner wrote:
Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Anyhow, I think we should standardise on zero as the initial
index to be as consistent as practicable.
If you want to suggest a default of zero for the first subscript of
an array in SQL, please don't confuse the issue by using any form
of the word standard in that proposal. There are ANSI and ISO
standards for SQL, and they require that the first element of an
array is one. I'm OK with *extending* the standard by *allowing*
other values, but let's not flaunt the standard and break existing
code by changing the *default*.
That's already possible:
postgres=# SELECT ('[0:3]={e1,e2,e3,e4}'::text[])[0];
text
--
e1
(1 row)
Not too convenient, but ...
You omitted my rider 'However, not with a religious zeal at the expense of
practical considerations!' Which was meant to cover concerns like yours.
Given its already possible I don't understand what you propose then. A
guc that allows changing the default? That would need to be included in
dumps and such and would make old dumps - which won't include an
explicit SET of the current value - ambigious to load. So that doesn't
seem to be a good idea either.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 4/3/13 10:34 AM, Gavin Flower wrote: Maybe we should adopt the famous compromise of '0.5'? +0.5. ;P -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 04/04/13 11:55, Jim Nasby wrote: On 4/3/13 10:34 AM, Gavin Flower wrote: Maybe we should adopt the famous compromise of '0.5'? +0.5. ;P Far too positive for our grim world! How about '-0,5' instead? :-) I notice you call yourself a 'Data Architect' - never too sure If I should call myself a 'software architect who pretends he can program' or a 'programmer with pretensions of being a software architect'? :-)
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 4 April 2013 01:10, Tom Lane t...@sss.pgh.pa.us wrote:
I think though that the upthread argument that we'd have multiple
interpretations of the same thing is bogus. To me, the core idea that's
being suggested here is that '{}' should mean a zero-length 1-D array,
not a zero-D array as formerly. We would still need a way to represent
zero-D arrays, if only because they'd still exist on-disk in existing
databases (assuming we're not willing to break pg_upgrade for this).
Tom,
My thought was that on-disk zero-D arrays should be converted into
empty 1-D arrays (with default lower bounds of course) when they are
read by array_recv. Any SQL operation on your zero-D arrays would
therefore resolve as though they were 1-D. A pg_dump/restore would
result in the arrays being 1-D on the restore side. If pg_upgrade
conserves the zero-D array in binary form, that's okay since the
receiving end will just treat it as 1-D out of array_recv anyway.
My intention was that the zero-D array could continue to live
indefinitely in binary form, but would never be observable as such by
any application code.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes: My thought was that on-disk zero-D arrays should be converted into empty 1-D arrays (with default lower bounds of course) when they are read by array_recv. Huh? array_recv would not get applied to datums coming off of disk. The only way to make this 100% transparent would be to go through every C-coded function that deals with arrays and make sure it delivers identical results for both cases. It's possible we could do that for array functions in the core code, but what about user-written extensions? In any case, the whole exercise is pointless if we don't change the visible behavior of array_dims et al. So I think the idea that this would be without visible consequence is silly. What's up for argument is just how much incompatibility is acceptable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 4 April 2013 15:11, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: My thought was that on-disk zero-D arrays should be converted into empty 1-D arrays (with default lower bounds of course) when they are read by array_recv. Huh? array_recv would not get applied to datums coming off of disk. My mistake, sorry for the noise. In any case, the whole exercise is pointless if we don't change the visible behavior of array_dims et al. So I think the idea that this would be without visible consequence is silly. What's up for argument is just how much incompatibility is acceptable. I don't know that anyone was suggesting there would be no visible consequences of any kind. I was hoping that we could at least represent on-disk zero-D arrays as though they were 1-D. If that's not going to fly, and we are stuck with continuing to allow zero-D as a valid representation, then perhaps your '[]=' syntax would be the way to proceed. It would not be terribly difficult to rework the patch along those lines, although I have to admit allow empty arrays with dimensions is not nearly so satisfying a title as exorcise zero-dimensional arrays. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 29/03/13 13:12, Brendan Jurd wrote:
On 28 March 2013 20:34, Dean Rasheed dean.a.rash...@gmail.com wrote:
Is the patch also going to allow empty arrays in higher dimensions
where not just the last dimension is empty?
It doesn't allow that at present.
It seems as though, if
it's allowing 1-by-0 arrays like '{{}}' and '[4:4][8:7]={{}}', it
should also allow 0-by-0 arrays like '[4:3][8:7]={}', and 0-by-3
arrays like '[4:3][11:13]={}'.
I think the array literal parser would reject this on the grounds that
the brace structure doesn't match the dimension specifiers. You could
modify that check to respect zero length in dimensions other than the
innermost one, but it's hard to say whether it would be worth the
effort.
It might be instructive to hear from somebody who does (or intends to)
use multidim arrays for some practical purpose, but I don't even know
whether such a person exists within earshot of this list.
Cheers,
BJ
Multiple dimension arrays. 'might' be something I may need, or at least
usefully use in my current project.
I am not ready to do the database design to that detail yet.
However, I know I will need to do 'clever'(TM) things with multiple
images areas on images, and possibly group several images together (and
still access their individual image areas). So potentially arrays of
dimension 2 or greater may be useful. Certainly, some images will not
have any image areas defined, some arrays might be empty.
Cheers,
Gavin
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd dire...@gmail.com wrote:
On 27 March 2013 06:47, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd dire...@gmail.com wrote:
We can't sensibly test for whether an array is empty. I'd call that a
functional problem.
Sure you can. Equality comparisons work just fine.
rhaas=# select '{}'::int4[] = '{}'::int4[];
The good news is, if anybody out there is using that idiom to test for
emptiness, they will not be disrupted by the change.
According to the discussion downthread, apparently they will, because
you're introducing an infinitude of empty arrays, not all of which
compare equal to '{}'::int4.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
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.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 1 April 2013 21:57, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd dire...@gmail.com wrote:
On 27 March 2013 06:47, Robert Haas robertmh...@gmail.com wrote:
rhaas=# select '{}'::int4[] = '{}'::int4[];
The good news is, if anybody out there is using that idiom to test for
emptiness, they will not be disrupted by the change.
According to the discussion downthread, apparently they will, because
you're introducing an infinitude of empty arrays, not all of which
compare equal to '{}'::int4.
It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in
existing applications, so there is no way for that idiom in existing
applications to be broken by upgrading. If testing for equality with
'{}' works now, it will also work post-upgrade.
The only way for it to stop working is if somebody upgrades, and
*then* goes out of their way to create an empty array with nondefault
lower bounds, and then tries to compare that array against the empty
array with default lower bounds, to test for emptiness. Which would
be silly.
Big picture: A very large number of users wouldn't be using arrays at
all, and of those who are, probably a vanishingly small number
(perhaps zero) care about how emptiness interacts with multiple
dimensions or nondefault lower bounds. We're talking about a corner
case inside a corner case here.
For most folks, this upgrade would break nothing. A few (myself
included) will want to grep their code for
array_(lower|upper|length|dims) call sites and maybe make some tweaks.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd dire...@gmail.com wrote:
It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in
existing applications, so there is no way for that idiom in existing
applications to be broken by upgrading. If testing for equality with
'{}' works now, it will also work post-upgrade.
I suppose, strictly speaking, that that is true, but I think there are
all kinds of ways for this to go wrong. Your previous complaint was
that there was no easy way to check whether an array is empty. I
pointed out that there is: compare it against an empty array and see
whether they are equal. Now you're saying, let's change it so we can
have lots of different empty arrays, each one different from all the
others. Well, that breaks the world for anybody who is using the
method that works today. Sure, they've probably got to have at least
some kind of application change before the wheels really start to come
off, but as soon as some array that's empty but not equal to {} creeps
into their application by whatever means, they've got trouble. And
what's the upside? Do we really want or need an infinitude of
all-distinct empty arrays?
Besides, even if you're not convinced that that particular thing will
break applications, there are clearly going to be cases where some
array functions return different results after this change than they
did beforehand. That's actually the whole point of this change.
Right? And, if you change the value that a built-in function returns
when given the same input, that can break user applications.
The only way for it to stop working is if somebody upgrades, and
*then* goes out of their way to create an empty array with nondefault
lower bounds, and then tries to compare that array against the empty
array with default lower bounds, to test for emptiness. Which would
be silly.
Big picture: A very large number of users wouldn't be using arrays at
all, and of those who are, probably a vanishingly small number
(perhaps zero) care about how emptiness interacts with multiple
dimensions or nondefault lower bounds. We're talking about a corner
case inside a corner case here.
I think the first half of this argument is off-point, because it's
true in general, for any feature, that people who aren't using a
feature won't notice if the behavior of that feature changes. But we
have good evidence that even obscure, largely broken features like
RULEs have user bases that are significant enough that changing the
behavior of those systems will generate protest. I'd be surprised if
the number of people using arrays isn't far larger than the number of
people using rules for table partitioning.
As to the second half, part of the point of this patch is to change
things so that array_length('{}'::int4[], 1) returns non-NULL. But I
myself have written code that tests for an empty array by writing
array_length(blahblah, 1) IS NULL. So with your proposed change, that
code would break. Sure, I would have been happier, when I wrote that
code, if the return value had been 0 rather than NULL. But the return
value *was* NULL, so I wrote the code that way, and it worked. I
can't be the only one to have done something like that. Anyone who
has would get an ugly surprise if we did what you're proposing. In a
large application, it might not even be clear (until you started
poking at it) what exactly had changed; and if they've got tens or
hundreds of thousands of lines of code (hardly unreasonable), fixing
it might be quite a chore. Imposing that pain our user base does not
seem justified to me.
For most folks, this upgrade would break nothing. A few (myself
included) will want to grep their code for
array_(lower|upper|length|dims) call sites and maybe make some tweaks.
I think the only people for whom nothing will break are the people who
aren't using arrays in the first place. Anyone who is is likely to
have dependencies on the way array_lower/upper work today.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Apr 1, 2013, at 4:59 PM, Robert Haas robertmh...@gmail.com wrote: I think the only people for whom nothing will break are the people who aren't using arrays in the first place. Anyone who is is likely to have dependencies on the way array_lower/upper work today. Well, what if we add new functions that return 0 for empty arrays, but leave the existing ones alone? Perhaps call them array_size(), array_first_index(), and array_last_index(). Then nothing has to break, and we can decide independently if we want to deprecate the older functions in a future release. Or not. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 2 April 2013 10:59, Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd dire...@gmail.com wrote:
It is not possible to construct e.g. '[3:2]={}' or '{{}, {}}' in
existing applications, so there is no way for that idiom in existing
applications to be broken by upgrading. If testing for equality with
'{}' works now, it will also work post-upgrade.
Sure, they've probably got to have at least
some kind of application change before the wheels really start to come
off, but as soon as some array that's empty but not equal to {} creeps
into their application by whatever means, they've got trouble.
Constructing an array with nondefault bounds isn't happening by
accident, you'd have to know about, and deliberately make use of, the
obscure '[m:n]={}' syntax for array literals. How is it going to
creep in?
I note the total absence of people rending their garments over the
fact that '{foo}' does not equal '[2:2]={foo}'.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 2 April 2013 11:34, David E. Wheeler da...@kineticode.com wrote: On Apr 1, 2013, at 4:59 PM, Robert Haas robertmh...@gmail.com wrote: I think the only people for whom nothing will break are the people who aren't using arrays in the first place. Anyone who is is likely to have dependencies on the way array_lower/upper work today. Well, what if we add new functions that return 0 for empty arrays, but leave the existing ones alone? Perhaps call them array_size(), array_first_index(), and array_last_index(). Then nothing has to break, and we can decide independently if we want to deprecate the older functions in a future release. Or not. I think having an 'array_size' and an 'array_length' that behave differently would be legitimately confusing, and I can't think of any alternative function name that would concisely explain the difference in behaviour -- 'array_length_without_the_stupid_nulls' is just too long. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Hello 2013/4/2 Brendan Jurd dire...@gmail.com On 2 April 2013 11:34, David E. Wheeler da...@kineticode.com wrote: On Apr 1, 2013, at 4:59 PM, Robert Haas robertmh...@gmail.com wrote: I think the only people for whom nothing will break are the people who aren't using arrays in the first place. Anyone who is is likely to have dependencies on the way array_lower/upper work today. Well, what if we add new functions that return 0 for empty arrays, but leave the existing ones alone? Perhaps call them array_size(), array_first_index(), and array_last_index(). Then nothing has to break, and we can decide independently if we want to deprecate the older functions in a future release. Or not. I think having an 'array_size' and an 'array_length' that behave differently would be legitimately confusing, and I can't think of any alternative function name that would concisely explain the difference in behaviour -- 'array_length_without_the_stupid_nulls' is just too long. yes, we should to do complete redesign or do nothing. Regards Pavel 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 28 March 2013 03:01, Tom Lane t...@sss.pgh.pa.us wrote:
[snip]
ranges *are not arrays*.
OK, fair enough. I guess it's the mathematician in me seeing patterns
in things that behave similarly, but which are admittedly different.
Is the patch also going to allow empty arrays in higher dimensions
where not just the last dimension is empty? It seems as though, if
it's allowing 1-by-0 arrays like '{{}}' and '[4:4][8:7]={{}}', it
should also allow 0-by-0 arrays like '[4:3][8:7]={}', and 0-by-3
arrays like '[4:3][11:13]={}'.
That last example seems like the more useful kind of thing to allow,
since you might one day be able to append a non-empty 1-D array onto
it. As it stands, the patch only allows empty 2-D arrays that are
empty in the final dimension, to which the only thing you could append
would be more empty 1-D arrays.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 28 March 2013 20:34, Dean Rasheed dean.a.rash...@gmail.com wrote:
Is the patch also going to allow empty arrays in higher dimensions
where not just the last dimension is empty?
It doesn't allow that at present.
It seems as though, if
it's allowing 1-by-0 arrays like '{{}}' and '[4:4][8:7]={{}}', it
should also allow 0-by-0 arrays like '[4:3][8:7]={}', and 0-by-3
arrays like '[4:3][11:13]={}'.
I think the array literal parser would reject this on the grounds that
the brace structure doesn't match the dimension specifiers. You could
modify that check to respect zero length in dimensions other than the
innermost one, but it's hard to say whether it would be worth the
effort.
It might be instructive to hear from somebody who does (or intends to)
use multidim arrays for some practical purpose, but I don't even know
whether such a person exists within earshot of this list.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 26 March 2013 20:44, 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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 28 March 2013 00:21, Dean Rasheed dean.a.rash...@gmail.com wrote:
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.
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.
Well the fix is primarily about 1-D empty arrays, and in that respect
it is much less confusing than what we have now. As for multidim
arrays, I don't use them in the field, so I don't have a strong
opinion about how (or even whether) we should support empty multidim.
I included the '{{}}' syntax following comments from Tom that we
should consider supporting that if we were to get rid of zero-D, but I
don't really have any skin in that game.
Since we require multidim arrays to be regular, perhaps they would
need extents in all dimensions to be practically useful ... if you
wanted to define a blank tic-tac-toe board using a 2-D array, for
example, you'd probably define it as 3x3 with NULL values in each
position, rather than trying to make it empty.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 27 March 2013 17:14, Brendan Jurd dire...@gmail.com wrote:
On 28 March 2013 00:21, Dean Rasheed dean.a.rash...@gmail.com wrote:
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.
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.
Well the fix is primarily about 1-D empty arrays, and in that respect
it is much less confusing than what we have now.
Maybe. But even in 1-D, it's still jumping from having one empty array
to infinitely many starting at different indexes, e.g., '{}'::int[] !=
'[4:3]={}'::int[]. There may be a certain logic to that, but I'm not
convinced about its usefulness.
Also, it is incompatible with the choice made for empty ranges, which
are all normalised to a single unique empty range value --- the empty
set, with no start- or end-points. I find that quite logical, and so
to me, it makes most sense to also have a single unique empty array,
which is then necessarily dimensionless.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 28 March 2013 09:39, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 27 March 2013 17:14, Brendan Jurd dire...@gmail.com wrote:
Well the fix is primarily about 1-D empty arrays, and in that respect
it is much less confusing than what we have now.
Maybe. But even in 1-D, it's still jumping from having one empty array
to infinitely many starting at different indexes, e.g., '{}'::int[] !=
'[4:3]={}'::int[]. There may be a certain logic to that, but I'm not
convinced about its usefulness.
We already have the ability to define lower bounds other than 1 on
arrays, and it would be inconsistent to allow that for arrays with
elements, but not for arrays without. I could imagine somebody
wanting to create an empty zero-based array, and then iteratively
append elements to it.
Also, it is incompatible with the choice made for empty ranges,
To me it doesn't make sense to try to draw parallels between arrays
and ranges, they really are completely different things.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes:
On 28 March 2013 09:39, Dean Rasheed dean.a.rash...@gmail.com wrote:
Maybe. But even in 1-D, it's still jumping from having one empty array
to infinitely many starting at different indexes, e.g., '{}'::int[] !=
'[4:3]={}'::int[]. There may be a certain logic to that, but I'm not
convinced about its usefulness.
We already have the ability to define lower bounds other than 1 on
arrays, and it would be inconsistent to allow that for arrays with
elements, but not for arrays without.
Yeah, if '[1:1]={0}'::int[] is distinct from '[2:2]={0}'::int[],
it's a bit hard to argue that '[1:0]={}'::int[] must not be
distinct from '[2:1]={}'::int[]. If we were doing this from scratch
we might drop the whole notion of nondefault lower bounds, but that
ship sailed ages ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
We already have the ability to define lower bounds other than 1 on arrays, and it would be inconsistent to allow that for arrays with elements, but not for arrays without. I could imagine somebody wanting to create an empty zero-based array, and then iteratively append elements to it. Hmmm. You know, I think that's why we originally had array_upper() on an empty array return NULL, not 0. -- 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: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 28 March 2013 00:04, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
On 28 March 2013 09:39, Dean Rasheed dean.a.rash...@gmail.com wrote:
Maybe. But even in 1-D, it's still jumping from having one empty array
to infinitely many starting at different indexes, e.g., '{}'::int[] !=
'[4:3]={}'::int[]. There may be a certain logic to that, but I'm not
convinced about its usefulness.
We already have the ability to define lower bounds other than 1 on
arrays, and it would be inconsistent to allow that for arrays with
elements, but not for arrays without.
Yeah, if '[1:1]={0}'::int[] is distinct from '[2:2]={0}'::int[],
it's a bit hard to argue that '[1:0]={}'::int[] must not be
distinct from '[2:1]={}'::int[]. If we were doing this from scratch
we might drop the whole notion of nondefault lower bounds, but that
ship sailed ages ago.
You could make the exact same argument for ranges --- if
'[1,1]'::int4range is distinct from '[2,2]'::int4range, why isn't
'[1,1)'::int4range distinct from '[2,2)'::int4range?
I see ranges and arrays as very closely related because the extents of
an array are an integer range, and the extents of an empty array are
an empty range. Moreover, they have almost identical API functions.
There are two internally self-consistent models for handling empty
ranges/arrays --- one in which empty ranges/arrays are considered not
to have lower/upper bounds, and one in which they are. In the first
model, there is only one empty range/array. In the second, there are
infinitely many, all different. Both models can be written in a
consistent way, but what seems inconsistent is to choose one model for
ranges, and change to a different model for arrays.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Dean Rasheed dean.a.rash...@gmail.com writes:
On 28 March 2013 00:04, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, if '[1:1]={0}'::int[] is distinct from '[2:2]={0}'::int[],
it's a bit hard to argue that '[1:0]={}'::int[] must not be
distinct from '[2:1]={}'::int[].
You could make the exact same argument for ranges --- if
'[1,1]'::int4range is distinct from '[2,2]'::int4range, why isn't
'[1,1)'::int4range distinct from '[2,2)'::int4range?
Because an array's bounds are a core piece of the identity of the
array. In another universe PG's arrays might not have been defined
like that, but as things stand, they are. We chose to define ranges
differently. That's okay, because ranges *are not arrays*. If they
were the same, we'd not have needed to invent a separate concept.
I see ranges and arrays as very closely related because the extents of
an array are an integer range, and the extents of an empty array are
an empty range. Moreover, they have almost identical API functions.
I think this argument has about as much validity as claiming that
because the subscripts of an array are integers, arrays should behave
like integers.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Sun, Mar 24, 2013 at 10:02 PM, Josh Berkus j...@agliodbs.com wrote: On 03/20/2013 04:45 PM, Brendan Jurd wrote: Incompatibility: This patch introduces an incompatible change in the behaviour of the aforementioned array functions -- instead of returning NULL for empty arrays they return meaningful values. Applications relying on the old behaviour to test for emptiness may be disrupted. One can As a heavy user of arrays, I support this patch as being worth the breakage of backwards compatibility. However, that means it certainly will need to wait for 9.4 to provide adequate warning. I expect to lose this argument, but I think this is a terrible idea. Users really hate it when they try to upgrade and find that they, uh, can't, because of some application-level incompatibility like this. They hate it twice as much when the change is essentially cosmetic. There's no functional problems with arrays as they exist today that this change would solve. The way to make a change like this without breaking things for users is to introduce a new type with different behavior and gradually deprecate the old one. Now, maybe it doesn't seem worth doing that for a change this small. But if so, I think that's evidence that this isn't worth changing in the first place, not that it's worth changing without regard for backwards-compatibility. Personally, I think if we're going to start whacking around the behavior here and risk inconveniencing our users, we ought to think a little larger. The fundamental thing that's dictating the current behavior is that we have arrays of between 1 and 6 dimensions all rolled up under a single data type. But in many cases, if not nearly all cases, what people want is, specifically, a one-dimensional array. If we were going to actually bite the bullet and create separate data types for each possible number of array dimensions... and maybe fix some other problems at the same time... then the effort involved in ensuring backward-compatibility might seem like time better spent. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
2013/3/26 Robert Haas robertmh...@gmail.com: On Sun, Mar 24, 2013 at 10:02 PM, Josh Berkus j...@agliodbs.com wrote: On 03/20/2013 04:45 PM, Brendan Jurd wrote: Incompatibility: This patch introduces an incompatible change in the behaviour of the aforementioned array functions -- instead of returning NULL for empty arrays they return meaningful values. Applications relying on the old behaviour to test for emptiness may be disrupted. One can As a heavy user of arrays, I support this patch as being worth the breakage of backwards compatibility. However, that means it certainly will need to wait for 9.4 to provide adequate warning. I expect to lose this argument, but I think this is a terrible idea. Users really hate it when they try to upgrade and find that they, uh, can't, because of some application-level incompatibility like this. They hate it twice as much when the change is essentially cosmetic. There's no functional problems with arrays as they exist today that this change would solve. The way to make a change like this without breaking things for users is to introduce a new type with different behavior and gradually deprecate the old one. Now, maybe it doesn't seem worth doing that for a change this small. But if so, I think that's evidence that this isn't worth changing in the first place, not that it's worth changing without regard for backwards-compatibility. Personally, I think if we're going to start whacking around the behavior here and risk inconveniencing our users, we ought to think a little larger. The fundamental thing that's dictating the current behavior is that we have arrays of between 1 and 6 dimensions all rolled up under a single data type. But in many cases, if not nearly all cases, what people want is, specifically, a one-dimensional array. If we were going to actually bite the bullet and create separate data types for each possible number of array dimensions... and maybe fix some other problems at the same time... then the effort involved in ensuring backward-compatibility might seem like time better spent. I understand, but I don't agree. W have to fix impractical design of arrays early. A ARRAY is 1st class - so there is not possible to use varchar2 trick. if we don't would to use GUC, what do you think about compatible extension? We can overload a system functions behave. This can solve a problem with updates and migrations. Regards Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 26 March 2013 22:57, Robert Haas robertmh...@gmail.com wrote:
They hate it twice as much when the change is essentially cosmetic.
There's no functional problems with arrays as they exist today that
this change would solve.
We can't sensibly test for whether an array is empty. I'd call that a
functional problem.
The NULL return from array_{length,lower,upper,ndims} is those
functions' way of saying their arguments failed a sanity check. So we
cannot distinguish in a disciplined way between a valid, empty array,
and bad arguments. If the zero-D implementation had been more
polished and say, array_ndims returned zero, we had provided an
array_empty function, or the existing functions threw errors for silly
arguments instead of returning NULL, then I'd be more inclined to see
your point. But as it stands, the zero-D implementation has always
been half-baked and slightly broken, we just got used to working
around it.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
I expect to lose this argument, but I think this is a terrible idea. Users really hate it when they try to upgrade and find that they, uh, can't, because of some application-level incompatibility like this. They hate it twice as much when the change is essentially cosmetic. There's no functional problems with arrays as they exist today that this change would solve. Sure there is. How do you distinguish between an array which is NULL and an array which is empty? Also, the whole array_dims is NULL thing trips up pretty much every single PG user who uses arrays for the first time. I'd expect when we announce the fix, we'll find that many users where doing the wrong thing in the first place and didn't know why it wasn't working. -- 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: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd dire...@gmail.com wrote:
On 26 March 2013 22:57, Robert Haas robertmh...@gmail.com wrote:
They hate it twice as much when the change is essentially cosmetic.
There's no functional problems with arrays as they exist today that
this change would solve.
We can't sensibly test for whether an array is empty. I'd call that a
functional problem.
Sure you can. Equality comparisons work just fine.
rhaas=# select '{}'::int4[] = '{}'::int4[];
?column?
--
t
(1 row)
rhaas=# select '{}'::int4[] = '{1}'::int4[];
?column?
--
f
(1 row)
The NULL return from array_{length,lower,upper,ndims} is those
functions' way of saying their arguments failed a sanity check. So we
cannot distinguish in a disciplined way between a valid, empty array,
and bad arguments. If the zero-D implementation had been more
polished and say, array_ndims returned zero, we had provided an
array_empty function, or the existing functions threw errors for silly
arguments instead of returning NULL, then I'd be more inclined to see
your point. But as it stands, the zero-D implementation has always
been half-baked and slightly broken, we just got used to working
around it.
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.
And if neither that nor just comparing against an empty array literal
floats your boat, adding an array_is_empty() function would let you
test for this condition without breaking backward compatibility, too.
That's overkill, I think, but it would work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 27 March 2013 06:47, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd dire...@gmail.com wrote:
We can't sensibly test for whether an array is empty. I'd call that a
functional problem.
Sure you can. Equality comparisons work just fine.
rhaas=# select '{}'::int4[] = '{}'::int4[];
The good news is, if anybody out there is using that idiom to test for
emptiness, they will not be disrupted by the change.
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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes: On 25 March 2013 13:02, Josh Berkus j...@agliodbs.com wrote: Brendan, how hard would it be to create a GUC for backwards-compatible behavior? Good idea. No, it *isn't* a good idea. GUCs that change application-visible semantics are dangerous. We should have learned this lesson by now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 26 March 2013 00:30, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: On 25 March 2013 13:02, Josh Berkus j...@agliodbs.com wrote: Brendan, how hard would it be to create a GUC for backwards-compatible behavior? Good idea. No, it *isn't* a good idea. GUCs that change application-visible semantics are dangerous. We should have learned this lesson by now. They are? Well okay then. I'm not deeply attached to the GUC thing, it just seemed like a friendly way to ease the upgrade path. But if it's dangerous somehow I'm happy to drop it. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com writes: On 26 March 2013 00:30, Tom Lane t...@sss.pgh.pa.us wrote: No, it *isn't* a good idea. GUCs that change application-visible semantics are dangerous. We should have learned this lesson by now. They are? Yeah, they are, because things break when they're set wrong. Sometimes we have to have one anyway, but AFAICS this patch is just proposing to change corner cases that most apps don't hit. I think we'd be better off without a knob for it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 21 March 2013 10:45, Brendan Jurd dire...@gmail.com wrote: src/test/isolation/expected/timeouts.out| 16 +- src/test/isolation/specs/timeouts.spec | 8 +- Oops, looks like some unrelated changes made their way into the original patch. Apologies. Here's a -v2 patch, sans stowaways. Cheers, BJ zero-length-array-v2.diff.bz2 Description: BZip2 compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
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. My thought was that we change the behavior in 9.4, provide a backwards-compatible GUC with warnings in the logs for two versions, and then take the GUC away. Whether that's worth the effort, though, is a question of how many people are going to be affected by the compatibility break. Maybe I can do a survey. -- 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: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 03/25/2013 10:28 PM, Tom Lane wrote: Yeah, they are, because things break when they're set wrong. They also make debugging and support harder; you need to get an ever-growing list of GUC values from the user to figure out what their query does. bytea_output, standard_conforming_strings, etc. Yick. That said, I don't have a better answer for introducing non-BC changes. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 2013.03.25 5:55 PM, Craig Ringer wrote: On 03/25/2013 10:28 PM, Tom Lane wrote: Yeah, they are, because things break when they're set wrong. They also make debugging and support harder; you need to get an ever-growing list of GUC values from the user to figure out what their query does. bytea_output, standard_conforming_strings, etc. Yick. That said, I don't have a better answer for introducing non-BC changes. Given the general trouble GUC values cause, is there a plan to deprecate and remove each of the existing ones over time? As long as post-removal there isn't any actual loss of functionality, but users might have to change their code to do it the one true way, that would seem a good thing. -- Darren Duncan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 2013.03.25 6:03 PM, Darren Duncan wrote: On 2013.03.25 5:55 PM, Craig Ringer wrote: On 03/25/2013 10:28 PM, Tom Lane wrote: Yeah, they are, because things break when they're set wrong. They also make debugging and support harder; you need to get an ever-growing list of GUC values from the user to figure out what their query does. bytea_output, standard_conforming_strings, etc. Yick. That said, I don't have a better answer for introducing non-BC changes. Given the general trouble GUC values cause, is there a plan to deprecate and remove each of the existing ones over time? As long as post-removal there isn't any actual loss of functionality, but users might have to change their code to do it the one true way, that would seem a good thing. -- Darren Duncan To clarify, I mean GUC related to backwards compatibility matters, such as bytea_output or standard_conforming_strings, things that affect the logical behavior of code. I don't mean all GUC, not at all, most of the ones I know about should remain configurable. -- Darren Duncan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Mon, Mar 25, 2013 at 10:14:15AM -0700, Josh Berkus 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. My thought was that we change the behavior in 9.4, provide a backwards-compatible GUC with warnings in the logs for two versions, and then take the GUC away. standard_conforming_strings is not a good example because it took 5+ years to implement the change, and issued warnings about non-standard use for several releases --- it is not a pattern to follow. -- 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Bruce Momjian br...@momjian.us writes: On Mon, Mar 25, 2013 at 10:14:15AM -0700, Josh Berkus wrote: 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. My thought was that we change the behavior in 9.4, provide a backwards-compatible GUC with warnings in the logs for two versions, and then take the GUC away. standard_conforming_strings is not a good example because it took 5+ years to implement the change, and issued warnings about non-standard use for several releases --- it is not a pattern to follow. s_c_s was an example of the worst possible case: where the behavioral change not merely breaks applications, but breaks them in a way that creates easily-exploitable security holes. We *had* to take that one really slow, and issue warnings for several years beforehand (and IIRC, there were still gripes from people who complained that we'd caused them security problems). I can't imagine that we'd go to that kind of trouble for any less-sensitive behavioral change. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 03/20/2013 04:45 PM, Brendan Jurd wrote: Incompatibility: This patch introduces an incompatible change in the behaviour of the aforementioned array functions -- instead of returning NULL for empty arrays they return meaningful values. Applications relying on the old behaviour to test for emptiness may be disrupted. One can As a heavy user of arrays, I support this patch as being worth the breakage of backwards compatibility. However, that means it certainly will need to wait for 9.4 to provide adequate warning. Brendan, how hard would it be to create a GUC for backwards-compatible behavior? -- 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: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 25 March 2013 13:02, Josh Berkus j...@agliodbs.com wrote: On 03/20/2013 04:45 PM, Brendan Jurd wrote: Incompatibility: This patch introduces an incompatible change in the behaviour of the aforementioned array functions -- instead of returning NULL for empty arrays they return meaningful values. Applications relying on the old behaviour to test for emptiness may be disrupted. One can As a heavy user of arrays, I support this patch as being worth the breakage of backwards compatibility. However, that means it certainly will need to wait for 9.4 to provide adequate warning. Thanks Josh, I appreciate the support. Brendan, how hard would it be to create a GUC for backwards-compatible behavior? Good idea. I don't know how hard it would be (never messed with GUCs before), but I'll take a swing at it and see how it works out. 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
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On Mar 20, 2013, at 4:45 PM, Brendan Jurd dire...@gmail.com wrote: I submit a patch to rectify the weird and confusing quirk of Postgres to use zero dimensions to signify an empty array. Epic. Thank you. I’m very glad now that I complained about this (again)! Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
