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:
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 |
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 |