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
