Re: operator exclusion constraints

On Sun, Sep 27, 2009 at 5:47 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 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.

In that case, I think we should target this for the next CommitFest.
Especially given the number and complexity of the patches remaining
for this CommitFest, I feel very uncomfortable with the idea of
waiting another week for a new patch version, and then possibly still
needing further changes before it is finally committed. While we
allow patches to be resubmitted for the same CommitFest, this is
intended to be for minor adjustments, not significant rewrites.

So I'm going to mark this Returned with Feedback.

...Robert