On 14 September 2017 at 03:49, Noah Misch <n...@leadboat.com> wrote: > On Wed, Sep 13, 2017 at 12:06:40PM -0400, Robert Haas wrote: >> OK, thanks. I still don't really like allowing this, but I can see >> that compatibility with other systems has some value here, and if >> nobody else is rejecting these cases, maybe we shouldn't either. So >> I'll hold my nose and change my vote to canonicalizing rather than >> rejecting outright. > > I vote for rejecting it. DDL compatibility is less valuable than other > compatibility. The hypothetical affected application can change its DDL to > placate PostgreSQL and use that modified DDL for all other databases, too.
So we have 3 options: 1. Do nothing, allowing and keeping any values after a MINVALUE/MAXVALUE. 2. Allow the such values, but canonicalise what we store. 3. Reject anything other than MINVALUE/MAXVALUE after MINVALUE/MAXVALUE. My order of preference is still (1), (2) then (3) because: - Compatibility. - Less verbose / easier to type. - We allow multiple syntaxes for equivalent constraints in other places, without canonicalising what the user enters. - Regarding Robert's coding argument, code in general should not be looking at and basing decisions on any values it sees after a MINVALUE/MAXVALUE. If it does, at the very least it's doing more work than it needs to, and at worst, there's a potential bug there which would be more readily exposed by allowing arbitrary values there. Code that only worked because because of earlier canonicalisation would strike me as being somewhat fragile. However, it seems that there is a clear consensus towards (2) or (3) and we have viable patches for each, although I'm not sure which of those the consensus is really leaning towards. Robert, since partitioning was originally your commit, and you know the wider codebase better, I'm happy to go with whatever you decide. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
