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

From Brendan Jurd
Subject Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Date
Msg-id CADxJZo2PwAgMPQbTyk1VYx8KuWQ=u1s+tzyVaQvH+3n_4wOKqA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
On 14 June 2013 03:53, David E. Wheeler <david@justatheory.com> wrote:
> Similar things should have dissimilar names. I propose:
>
> <bikeshedding>
>
>      Old      |    New
> --------------+--------------
>  array_dims   | array_desc

array_bounds?

>  array_ndims  | array_depth
>  array_length | array_size
>  array_lower  | array_start
>  array_upper  | array_finish
>
> The last two are meh, but it’s a place to start…

I think that even with the most dissimilar names we can come up with,
this is going to confuse people.  But it is still better than doing
nothing.

I wonder whether, if we go in this direction, we could still use some
of the work I did on deprecating zero-D arrays.  Let's say the old
functions keep doing what they do now, and we teach them to treat all
empty arrays the same way they currently treat zero-D arrays (return
NULL).  The new functions treat zero-D arrays as though they were 1-D
empty with default bounds, and we add CARDINALITY per ArrayGetNItems.

This way, applications would not be broken by upgrading, and we'd be
giving people a way to opt-in to a better API.

Cheers,
BJ



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Hard to Use WAS: Hard limit on WAL space
Next
From: Brendan Jurd
Date:
Subject: Re: Hard to Use WAS: Hard limit on WAL space