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

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Date: 2013-04-02 18:46:00
Message-ID: 04C2B03E-EB3B-4B99-A7FB-42517AF385D7@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Apr1, 2013, at 13:43 , Robert Haas <robertmhaas(at)gmail(dot)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 dimensionless. Is that the behavior I would
> have picked if I had designed the type? No, it isn't. I wouldn't
> have tried to support one-dimensional arrays and multi-dimensional
> arrays in the same data type either, nor would I have supported
> non-default lower bounds. But all of those ships have sailed, and the
> time to change them is not after people have spent 10 years building
> applications that work with the current behavior. If we want to
> introduce a new type with different, perhaps better, behavior, well, I
> think that might be a fine idea. But I *don't* think imposing a hard
> compatibility break on users of arrays is a good idea.

+1.

Especially since having infinitely many variants of "empty" is IMHO
hardly an improvement over the existing situation.

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…

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-04-02 19:24:23 Re: Drastic performance loss in assert-enabled build in HEAD
Previous Message Atri Sharma 2013-04-02 18:45:56 Re: Page replacement algorithm in buffer cache