Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
