Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1259228029.19289.515.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: operator exclusion constraints
Re: operator exclusion constraints |
Список | pgsql-hackers |
On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote: > Forgive me if this is discussed before, but why does this store the > strategy numbers of the relevant operators instead of the operators > themselves? It seems like this could lead to surprising behavior if > the user modifies the definition of the operator class. Still open. > I'm wondering if we can't use the existing > BuildIndexValueDescription() rather than the new function > tuple_as_string(). I realize there are two tuples, but maybe it makes > sense to just call it twice? Changed. > I'm attaching a revised doc patch for your consideration. Thanks, I applied it. The only significant thing I changed was that I did not inline the "index_elem" because it made it fairly hard to read. Instead, I renamed it "exclude_elem" to make it a little more meaningful, which I assume may have been your motivation for inlining it. Changes this patch: * doc changes * changed constraint violation message to be more like btree unique violation * improved error message when an operator is specified that doesn't have a search strategy Remaining issues: * represent operator IDs in catalog, rather than strategy numbers * if someone thinks it's an issue, support search strategies that require binary-incompatible casts of the inputs Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: