Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 8 April 2013 16:09, Tom Lane wrote: > Brendan Jurd 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 prete

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 7 April 2013 01:43, Kevin Grittner 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 > mim

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 7 April 2013 01:43, Kevin Grittner wrote: > Brendan Jurd 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd wrote: > On 6 April 2013 01:59, Kevin Grittner wrote: >> Brendan Jurd 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 ele

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 6 April 2013 01:59, Kevin Grittner wrote: > Brendan Jurd 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 arra

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd 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.

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 5 April 2013 15:05, Tom Lane wrote: > Brendan Jurd 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 woul

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 5 April 2013 13:04, Tom Lane 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 5 April 2013 13:04, Tom Lane 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 "coll

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd 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 co

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 5 April 2013 07:43, Tom Lane 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 whil

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Robert Haas writes: > On Thu, Apr 4, 2013 at 11:10 AM, Merlin Moncure 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

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 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 Compa

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 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

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 Lane 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.

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4 April 2013 15:11, Tom Lane wrote: > Brendan Jurd 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 dis

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd 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 wo

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 4 April 2013 01:10, Tom Lane 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

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 mys

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@po

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 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

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 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

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 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 irrationali

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Gavin Flower 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 prop

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. Fortra

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

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_langua

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Tom Lane 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 3 April 2013 15:10, Tom Lane 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

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 wrote: > On Apr 3, 2013, at 9:30 AM, Tom Lane 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 clearl

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 lang

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr 3, 2013, at 9:30 AM, Tom Lane 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 c

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

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 (Wi

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

2013/4/3 Gavin Flower > On 04/04/13 04:58, Pavel Stehule wrote: > > > > > 2013/4/3 Gavin Flower > >> On 04/04/13 03:02, Florian Pflug wrote: >> >>> On Apr3, 2013, at 15:30 , Andrew Dunstan wrote: >>> On 04/02/2013 02:46 PM, Florian Pflug wrote: > If we're going to break compatibi

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 > On 04/04/13 03:02, Florian Pflug wrote: On Apr3, 2013, at 15:30 , Andrew Dunstan mailto:and...@dunslane.net>> wrote: On 04/02/2013 02:46 PM, Florian Pflug wrote:

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

2013/4/3 Gavin Flower > On 04/04/13 03:02, Florian Pflug wrote: > >> On Apr3, 2013, at 15:30 , Andrew Dunstan 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

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 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 mu

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Andrew Dunstan 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 l

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr3, 2013, at 15:30 , Andrew Dunstan 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 p

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 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 ar

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr1, 2013, at 13:43 , Robert Haas 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

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 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 '{{}}' a

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Hello 2013/4/2 Brendan Jurd > On 2 April 2013 11:34, David E. Wheeler wrote: > > On Apr 1, 2013, at 4:59 PM, Robert Haas 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 de

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2 April 2013 11:34, David E. Wheeler wrote: > On Apr 1, 2013, at 4:59 PM, Robert Haas 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 2 April 2013 10:59, Robert Haas wrote: > On Mon, Apr 1, 2013 at 6:40 PM, Brendan Jurd 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 eq

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Apr 1, 2013, at 4:59 PM, Robert Haas 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 retur

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 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 1 April 2013 21:57, Robert Haas wrote: > On Tue, Mar 26, 2013 at 4:39 PM, Brendan Jurd wrote: >> On 27 March 2013 06:47, Robert Haas wrote: >>> rhaas=# select '{}'::int4[] = '{}'::int4[]; >> >> The good news is, if anybody out there is using that idiom to test for >> emptiness, they will not

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 wrote: On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane wrote: Robert Haas 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'

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 wrote: > On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane wrote: >> Robert Haas 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 b

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 wrote: > Robert Haas 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 e

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 wrote: > On 27 March 2013 06:47, Robert Haas wrote: >> On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd wrote: >>> We can't sensibly test for whether an array is empty. I'd call that a >>> functional problem. >> >> Sure you can. Equality comparisons w

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 20:34, Dean Rasheed 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 a

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 03:01, Tom Lane 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Dean Rasheed writes: > On 28 March 2013 00:04, Tom Lane 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 00:04, Tom Lane wrote: > Brendan Jurd writes: >> On 28 March 2013 09:39, Dean Rasheed 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

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.

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 28 March 2013 09:39, Dean Rasheed 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 >> convinc

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 09:39, Dean Rasheed wrote: > On 27 March 2013 17:14, Brendan Jurd 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 in

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 27 March 2013 17:14, Brendan Jurd wrote: > On 28 March 2013 00:21, Dean Rasheed 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 "mo

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 28 March 2013 00:21, Dean Rasheed 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 26 March 2013 20:44, Tom Lane wrote: > Robert Haas 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Robert Haas 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 th

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 27 March 2013 06:47, Robert Haas wrote: > On Tue, Mar 26, 2013 at 9:02 AM, Brendan Jurd 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[]

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 wrote: > On 26 March 2013 22:57, Robert Haas 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 fo

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 fu

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 26 March 2013 22:57, Robert Haas 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 pro

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

2013/3/26 Robert Haas : > On Sun, Mar 24, 2013 at 10:02 PM, Josh Berkus 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 >>>

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 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 v

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Bruce Momjian 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 ex

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

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 u

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. byte

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. Y

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 t

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 21 March 2013 10:45, Brendan Jurd 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. Che

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 26 March 2013 00:30, Tom Lane 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 26 March 2013 00:30, Tom Lane wrote: > Brendan Jurd writes: >> On 25 March 2013 13:02, Josh Berkus 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

Brendan Jurd writes: > On 25 March 2013 13:02, Josh Berkus 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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On 25 March 2013 13:02, Josh Berkus 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. Ap

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

Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: [HACKERS] Should array_length() Return NULL)

On Mar 20, 2013, at 4:45 PM, Brendan Jurd 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 mail