Re: Possible marginally-incompatible change to array subscripting - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Possible marginally-incompatible change to array subscripting
Date
Msg-id 567A0EDB.3000600@BlueTreble.com
Whole thread Raw
In response to Re: Possible marginally-incompatible change to array subscripting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Possible marginally-incompatible change to array subscripting
List pgsql-hackers
On 12/22/15 12:01 PM, Tom Lane wrote:
> Yury Zhuravlev <u.zhuravlev@postgrespro.ru> writes:
>> If you break backwards compatibility, it can be done arrays
>> similar to C/C++/Python/Ruby and other languages style?
>> I'm sorry to bring up this thread again...
>
> I am not sure just exactly how incompatible that would be, but surely it
> would break enormously more code than what we're discussing here.
> So no, I don't think any such proposal has a chance.  There are degrees
> of incompatibility, and considering a small/narrow one does not mean that
> we'd also consider major breakage.

As I see it, the biggest problem with our arrays is that they can't 
decide if they're a simple array (which means >1 dimension is an array 
of arrays) or a matrix (all slices in a dimension must be the same 
size). They seem to be more like matricies than arrays, but then there's 
a bunch of places that completely ignore dimensionality. It would be 
nice to standardize them one way or another, but it seems like the 
breakage from that would be horrific.

One could theoretically construct a custom "type" that followed more 
traditional semantics, but then you'd lose all the syntax... which I 
suspect would make any such "type" all but unusable. The other problem 
would be having it deal with any other data type, but at least there's 
ways you can work around that for the most part.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Thomas Munro
Date:
Subject: Re: Support for N synchronous standby servers - take 2