Exclusion constraints are good. There's a few annoyances around them, that are minor but feel should be addressed for 9.0.
* Exclusion indexes are created with the suffix "_exclusion". That's a very long suffix and will overflow most defined reports/screens. It would be much better to use just "_excl", so that the number of characters for index suffixes is always 4 or less characters, whatever type of index they are. * Circles, Boxes and other geometric datatypes defined "overlaps" to include touching shapes. So SELECT circle '((0,0), 1)' && circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. * inet datatypes don't have a commutative operator on which a unique index can be built. There is no "overlaps" equivalent, which again is a shame because that stops them being used with the new feature. That leaves me thinking that we're shipping Postgres 9.0 with a new feature that isn't real-world usable with built-in datatypes. It's not even easily usable for demo applications either with the noddy datatypes. I do appreciate that the main use case is with add-in datatypes but this is a shame for such a great feature. Also, if the only common sense usage of exclusion constraints is GIST, why does the syntax default to "btree"? This means that alter table boxes add exclude using gist (position with &&); is required, to avoid this ERROR alter table boxes add exclude (position with &&); ERROR: data type box has no default operator class for access method "btree" HINT: You must specify an operator class for the index or define a default operator class for the data type. Surely in the absence of a relevant btree operator class we should automatically check for GIST operator classes? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
