Re: operator exclusion constraints

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: operator exclusion constraints
Date: 2009-11-14 19:27:29
Message-ID: 1258226849.708.97.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

New patches attached. You may find it easiest to follow the changes I'm
making through my git repo:

http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=shortlog;h=refs/heads/operator-exclusion-constraints

Note, the attached patches also changed CHECK WITH to just WITH, as
concluded in this discussion:

http://archives.postgresql.org/pgsql-hackers/2009-11/msg00785.php

On Fri, 2009-11-13 at 23:39 -0500, Robert Haas wrote:
> I think the create_table documentation gets into a little too much
> gorey detail. I'm willing to take a pass at improving it, if you'd
> like, but generally I think it should avoid discussion of
> implementation details. For example, saying that it's not as fast as
> a UNIQUE constraint is good; the fact that an extra index lookup is
> involved is probably overkill. Incidentally, the wording in the
> first paragraph fails to take into account the possibility that there
> are multiple operators.

Fixed. Of course, I welcome any further revisions you have.

> There is a spurious diff hunk for reindex_relation().

Fixed.

> In ATRewriteTable() you reindent a bunch of variable declarations;
> pg_indent will undo this, so you should nix this part.

Fixed.

> In ATAddOperatorExclusionConstraint(), the message "method %s does not
> support gettuple" seems a bit user-unfriendly. Can we explain the
> problem by referring to the functionality of getttuple(), rather than
> the name of it?

Now it looks like:

ERROR: method "gin" does not support operator exclusion constraints
DETAIL: The index access method must support the gettuple() interface
to be used with an operator exclusion constraint.

Hopefully that is an improvement.

> alter table X add constraint Y exclude (...) seems to ignore the value
> of Y and create both the constraint and the index with a name of its
> own choosing.

Bug, and fixed.

> I think preprocessOpExConstraints should be called
> transformOpxConstraints - opx rather than opex because that's what you
> most frequently use elsewhere in the patch, and transform rather than
> preprocess for consistency with other, similar functions.

Fixed.

> In ruleutils.c, the prototype for pg_get_opxdef_worker() has a small
> whitespace inconsistency relative to the surrounding declarations.

Fixed.

Thanks,
Jeff Davis

Attachment Content-Type Size
operator-exclusion-constraints-20091114.context.patch text/x-patch 100.3 KB
operator-exclusion-constraints-20091114.patch.gz application/x-gzip 24.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-14 19:27:37 Re: Inspection of row types in pl/pgsql and pl/sql
Previous Message Andrew Dunstan 2009-11-14 19:06:40 Re: Inspection of row types in pl/pgsql and pl/sql