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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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:
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
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
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
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
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
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
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
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,
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.
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.
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.
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
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
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
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
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
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
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
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%
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.,
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
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
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
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
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
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
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=#
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
83 matches
Mail list logo
