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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Date: 2013-04-03 19:33:05
Message-ID: 20130403193305.GF27856@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-04-04 08:03:03 +1300, Gavin Flower wrote:
> On 04/04/13 07:58, Kevin Grittner wrote:
> >Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> wrote:
> >
> >>Anyhow, I think we should standardise on zero as the initial
> >>index to be as consistent as practicable.
> >If you want to suggest a default of zero for the first subscript of
> >an array in SQL, please don't confuse the issue by using any form
> >of the word "standard" in that proposal. There are ANSI and ISO
> >standards for SQL, and they require that the first element of an
> >array is one. I'm OK with *extending* the standard by *allowing*
> >other values, but let's not flaunt the standard and break existing
> >code by changing the *default*.

That's already possible:

postgres=# SELECT ('[0:3]={e1,e2,e3,e4}'::text[])[0];
text
------
e1
(1 row)

Not too convenient, but ...

> You omitted my rider 'However, not with a religious zeal at the expense of
> practical considerations!' Which was meant to cover concerns like yours.

Given its already possible I don't understand what you propose then. A
guc that allows changing the default? That would need to be included in
dumps and such and would make old dumps - which won't include an
explicit SET of the current value - ambigious to load. So that doesn't
seem to be a good idea either.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-04-03 19:50:57 Re: commit dfda6ebaec67 versus wal_keep_segments
Previous Message Rodrigo Barboza 2013-04-03 19:25:42 Re: c language functions