Re: Some array semantics issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some array semantics issues
Date
Msg-id 336.1132255789@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some array semantics issues  (Greg Stark <gsstark@mit.edu>)
Responses Re: Some array semantics issues  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I don't have a lot of use for arguments that go "we should remove any
>> functionality that's not in the spec" ... ISTM that variable lower
>> bounds are clearly useful for some applications, and even if they had
>> bugs in earlier releases that's not an argument for removing them.

> Normally I don't either. But it's not just functionality that's not in the
> spec. It's functionality that creates behaviour the spec specifies otherwise.

AFAICS the only cases that give rise to arrays with lower bounds other
than one are:* direct entry of a literal with explicit lower bound;* assignment to a subscript or slice below 1;*
array_prepend(and the N/N+1-dimension case of array_cat).
 

I don't think "it's not in the spec" is a reason for rejecting #1 or #2.
But I agree that there is a reasonable case for modifying array_prepend
and array_cat so that they won't generate non-spec lower bounds where
none existed before.

How about changing them so that the lower bound of the right-hand array
is preserved, rather than decreased by one?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Improving count(*)
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Improving count(*)