From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Disallow arrays with non-standard lower bounds |
Date: | 2014-01-14 01:21:39 |
Message-ID: | 52D49123.9010006@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/13/14, 7:10 PM, Kevin Grittner wrote:
> Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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.
To be clear: I am completely fine with continuing to support custom lower bounds (to quote my original email: "Obviously we can't just drop support, but what about an initdb (or hell, even configure) option to disallow arrays with a lower bound <> 1?").
It might also be possible to protect users on the access side instead: provide alternate functions that protect you if you pass them an array that does have a custom lower bound. But I'm not so sure that'll work out, since one of the biggest offenders here is:
FOR i IN 1..array_upper(some_array) LOOP.
Yes, today you can use FOREACH, but what about all your legacy code that's ass-u-ming that the lower bound is 1?
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-01-14 01:26:25 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Previous Message | Andres Freund | 2014-01-14 01:18:51 | Re: Hot standby 9.2.6 -> 9.2.6 PANIC: WAL contains references to invalid pages |