Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think the argument really is that some people don't want to
> make their application code work with such cases (which is fine)
> so they'd like an inside-the-database guarantee that the app code
> won't ever see such cases. Which is less fine, ISTM: if you fear
> some part of your app might be generating such arrays, then you
> don't have such little use for the feature after all, eh?
While I don't see the argument for dropping support for lower
bounds other than 1 as long as standard syntax for creating arrays
yields arrays staring at 1, this argument holds no water at all. I
have done too many conversions from databases which did not enforce
data integrity rules not to have a lot of sympathy for people
wanting to have the ability to easily constrain data to whatever
their business rules say it should look like. The fact that some
day some new programmer might not be aware of all business rules,
or might choose to try to ignore them is the reason you add
constraints to columns and domains.
I think providing functions that make it easy to enforce this rule
make a lot of sense, as it would make a lot of application code
simpler, easier to read, and less fragile. I support overloading
functions with simpler parameter lists for standard-conforming
arrays; I don't support dropping support for whoever might be using
non-conforming arrays. A veriable lower bound is an extension to
the standard, and extensions are fine.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company