Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1258226849.708.97.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: operator exclusion constraints
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: