Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1254088023.5640.192.camel@jdavis обсуждение исходный текст |
Ответ на | operator exclusion constraints [was: generalized index constraints] (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: operator exclusion constraints
|
Список | pgsql-hackers |
Attached is a new patch. I ran it through filterdiff, but in case that didn't work for some reason, I attached a gzipped version of the original unified diff produced by git. * Changed underlying algorithm to match Tom's suggestion: do the second index lookup after already inserting into the first. * Language changes, including the latest "<expression> CHECK WITH <op>" idea from Tom, seconded by Robert Haas. * automatically builds index for you, no need to create it separately, just specify the index AM (or let it default to btree) * Only one constraint per index is allowed, and the index is treated entirely as an internal implementation detail. * Support for predicates (partial constraints/partial index) * Support for expressions * Support for other index options, like WITH list and USING INDEX TABLESPACE * Docs updated and improved * Tests updated * Full recheck support (the previous recheck mechanism didn't work for expressions) * Make information_schema ignore operator exclusion constraints * error message improvements When testing/reviewing, use the documentation from CREATE TABLE, but use the ALTER TABLE variant instead. Right now the CREATE TABLE variant doesn't work (see below). There is still a significant TODO list: * CREATE TABLE -- right now, it only works for ALTER TABLE, and the docs are lying. Coming soon. * psql - haven't updated it to keep up with the language changes * pg_dump * LIKE * Inheritance * Enforce on existing tuples when the constraint is created -- This is intertwined with inheritance, I think, and I am still working on that. Obviously, this is an important TODO item to get the patch ready for commit. * Deferrability (optional for now) -- I need the trigger to be able to perform the check as well. It looks like it has most of the information necessary, but I'm trying to determine where would be the cleanest place to export the constraint checking function so that it can be called by the trigger as well as ExecInsertIndexTuples and the bulk checker (that checks existing tuples at the time the constraint is added). * GIN support (optional for now) -- I need to create a gingettuple method. It would have to be a wrapper around gingetbitmap, and would not be any more efficient than gingetbitmap, but it would allow my patch to work for GIN indexes. I think I've made some progress this commitfest, both in terms of decisions made (thanks to everyone who provided input and direction), and also in terms of code. I would still appreciate more review during this commitfest, but realistically, it will still be at least another week before I can say that I'm done with all open items. Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: