Re: Some array semantics issues
От
Joe Conway
Тема
Re: Some array semantics issues
Дата
Msg-id
437BD705.7040501@joeconway.com
Ответ на
Re: Some array semantics issues (Greg Stark)
Список
Дерево обсуждения
Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Greg Stark <gsstark@mit.edu>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Greg Stark <gsstark@mit.edu>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Greg Stark <gsstark@mit.edu>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Joe Conway <mail@joeconway.com>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Joe Conway <mail@joeconway.com>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Greg Stark <gsstark@mit.edu>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Joe Conway <mail@joeconway.com>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Joe Conway <mail@joeconway.com>
Re: Some array semantics issues David Fetter <david@fetter.org>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Tom Lane <tgl@sss.pgh.pa.us>
Re: Some array semantics issues Joe Conway <mail@joeconway.com>
Greg Stark wrote: > Tom Lane writes: >>Joe Conway writes: >>>First, the spec only allows arrays to have a lower bound of 1. That >>>requirement simplifies a whole lot of things. I don't think that many >>>people actually depend on other than 1 as a lower bound (or at least if >>>they do, they weren't dumping and reloading those databases prior to >>>8.0) -- maybe given other possibly non-backward compatible changes for >>>NULLs, we should also change this? >> >>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. This is an important point. SQL2003 doesn't leave this as undefined: 4.10.2 Arrays An array is a collection A in which each element is associated with exactly one ordinal position in A. If n is the cardinality of A, then the ordinal position p of an element is an integer in the range 1 (one) <= p <= n. If EDT is the element type of A, then A can thus be considered as a function of the integers in the range 1 (one) to n into EDT. Joe
В списке pgsql-hackers по дате отправления
От: Christopher Kings-Lynne
Дата: