From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Some array semantics issues |
Date: | 2005-11-17 19:29:49 |
Message-ID: | 336.1132255789@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-11-17 19:38:16 | Re: Improving count(*) |
Previous Message | Simon Riggs | 2005-11-17 19:28:10 | Improving count(*) |