On Mon, Mar 22, 2010 at 9:15 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > 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.
I'd be OK with that. > * 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. As a non-user of geometric datatypes, I have no opinion on this one way or the other. > * 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. This would be a nice thing to fix, and I was thinking about doing it, but I just ran out of time. I think it can be left for 9.1. I have not infrequently wanted to build an IP allocation database, and this would be perfect for that. > 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? That doesn't seem particularly consistent with what we've done elsewhere. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
