On Thu, Jun 20, 2013 at 06:28:07PM -0700, Josh Berkus wrote:
> Bruce,
>
> > Well, sometimes we underestimate the impact of changes, sometimes we
> > overestimate. The big problem is weighing the short-term problems of
> > change but not the long-term benefit of a change. This array problem
> > g
Bruce,
> Well, sometimes we underestimate the impact of changes, sometimes we
> overestimate. The big problem is weighing the short-term problems of
> change but not the long-term benefit of a change. This array problem
> goes back to at least 2008:
>
> http://www.postgresql.org/message-i
On Thu, Jun 20, 2013 at 07:13:48PM -0500, Merlin Moncure wrote:
> On Thu, Jun 20, 2013 at 6:40 PM, Bruce Momjian wrote:
> >> Kinda -- what I'm saying is you just don't go around changing function
> >> behaviors to make them 'better' unless the affected behavior was
> >> specifically reserved as un
On Thu, Jun 20, 2013 at 6:40 PM, Bruce Momjian wrote:
>> Kinda -- what I'm saying is you just don't go around changing function
>> behaviors to make them 'better' unless the affected behavior was
>> specifically reserved as undefined. The fact is nobody knows how many
>> users will be affected an
On Thu, Jun 20, 2013 at 03:33:24PM -0500, Merlin Moncure wrote:
> On Thu, Jun 20, 2013 at 2:58 PM, Bruce Momjian wrote:
> > On Thu, Jun 13, 2013 at 11:57:27AM -0500, Merlin Moncure wrote:
> >> >> But, couldn't that be solved by deprecating that function and
> >> >> providing a more sensible altern
On Thu, Jun 20, 2013 at 2:58 PM, Bruce Momjian wrote:
> On Thu, Jun 13, 2013 at 11:57:27AM -0500, Merlin Moncure wrote:
>> >> But, couldn't that be solved by deprecating that function and
>> >> providing a more sensible alternatively named version?
>> >
>> > And what would you name that function?
On Thu, Jun 13, 2013 at 11:57:27AM -0500, Merlin Moncure wrote:
> >> But, couldn't that be solved by deprecating that function and
> >> providing a more sensible alternatively named version?
> >
> > And what would you name that function? array_dims2? I can't think of
> > a name that makes the dif
On 14 June 2013 03:53, David E. Wheeler wrote:
> Similar things should have dissimilar names. I propose:
>
>
>
> Old |New
> --+--
> array_dims | array_desc
array_bounds?
> array_ndims | array_depth
> array_length | array_size
> array_lower | array_s
On Jun 12, 2013, at 8:00 PM, Brendan Jurd wrote:
> array_dims - Returns the dimensions of the array, unless it is empty
> in which case NULL.
> array_proper_dims - Returns the dimensions of the array.
> array_ndims - Returns the number of dimension, unless it is empty in
> which case NULL.
> arra
On Wed, Jun 12, 2013 at 10:00 PM, Brendan Jurd wrote:
> On 13 June 2013 04:26, Merlin Moncure wrote:
>> On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane wrote:
>>> Josh Berkus writes:
On 06/12/2013 11:01 AM, Tom Lane wrote:
> I'm going to be disappointed if all we can get out of this is
>
On 13 June 2013 04:26, Merlin Moncure wrote:
> On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> On 06/12/2013 11:01 AM, Tom Lane wrote:
I'm going to be disappointed if all we can get out of this is
a cardinality() function, and nothing is done about the empty
On 2013.06.12 10:11 AM, Josh Berkus wrote:
Multidim arrays are why we can't have nice things.
Yeah, I think that was not our best moment. :-(
Actually, if you think about it, we've never had "arrays" in PostgreSQL
... we have always had matrixes. If you think about things that way,
most of
On Wed, Jun 12, 2013 at 1:20 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/12/2013 11:01 AM, Tom Lane wrote:
>>> I'm going to be disappointed if all we can get out of this is
>>> a cardinality() function, and nothing is done about the empty-array
>>> semantics.
>
>> Well, we can't change the
Josh Berkus writes:
> On 06/12/2013 11:01 AM, Tom Lane wrote:
>> I'm going to be disappointed if all we can get out of this is
>> a cardinality() function, and nothing is done about the empty-array
>> semantics.
> Well, we can't change the zero-dim behavior without breaking backwards
> compatibil
On 06/12/2013 11:01 AM, Tom Lane wrote:
> Arguably, the only thing wrong with multidim arrays is that they're not
> what the SQL standard asks for. However, the original point in this
> thread was that we have some very bizarre corner-case behavior for empty
> arrays. I'm going to be disappointe
Josh Berkus writes:
> Actually, if you think about it, we've never had "arrays" in PostgreSQL
> ... we have always had matrixes. If you think about things that way,
> most of the current functionality makes sense.
Arguably, the only thing wrong with multidim arrays is that they're not
what the S
>> Multidim arrays are why we can't have nice things.
>
> Yeah, I think that was not our best moment. :-(
They were one of those hacks which looked really clever at the time, but
proved not to be so. Unfortunately, they *are* useful, and are being
used; I use MD arrays all the time to push dat
On Wed, Jun 12, 2013 at 5:05 AM, Brendan Jurd wrote:
> On 12 June 2013 18:22, Dean Rasheed wrote:
>> +1 for having a function to return the total number of elements in an
>> array, because that's something that's currently missing from SQL.
>>
>> However, I think that CARDINALITY() should be that
On 12 June 2013 18:22, Dean Rasheed wrote:
> +1 for having a function to return the total number of elements in an
> array, because that's something that's currently missing from SQL.
>
> However, I think that CARDINALITY() should be that function.
>
> I'm not convinced that having CARDINALITY() r
On 12 June 2013 04:50, David E. Wheeler wrote:
> On Jun 11, 2013, at 3:09 PM, Brendan Jurd wrote:
>
>> There have been attempts to add a cardinality function in the past, as
>> it is required by the SQL spec, but these attempts have stalled when
>> trying to decide how it should handle multidim a
On Jun 11, 2013, at 3:09 PM, Brendan Jurd wrote:
> There have been attempts to add a cardinality function in the past, as
> it is required by the SQL spec, but these attempts have stalled when
> trying to decide how it should handle multidim arrays. Having it
> return the length of the first dim
21 matches
Mail list logo
