| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Matija Lesar <matija(dot)lesar(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Unexpected array_remove results |
| Date: | 2015-03-20 13:58:15 |
| Message-ID: | 25825.1426859895@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Matija Lesar <matija(dot)lesar(at)gmail(dot)com> writes:
> should not in example below array_remove return same results?
AFAICS, array_remove keeps the existing lower bound number. I don't
see anything particularly wrong with that definition.
Even if we didn't care about backwards compatibility, it would require
nontrivial effort to change it --- for example, there are several
early-exit cases that return the original array unmodified, and that would
be wrong if we were to adopt some other definition such as "force the
lower bound to 1".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Borodin | 2015-03-20 15:00:16 | Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary |
| Previous Message | Matija Lesar | 2015-03-20 06:37:32 | Unexpected array_remove results |