Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1258552809.19351.25.camel@jdavis-laptop обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: operator exclusion constraints
Re: operator exclusion constraints |
Список | pgsql-hackers |
I'm in Tokyo right now, so please excuse my abbreviated reply. 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? At constraint definition time, I need to make sure that the strategy numbers can be identified anyway, so it wouldn't save any work in ATAddOperatorExclusionConstraint. At the time it seemed slightly more direct to use strategy numbers in index_check_constraint, but it's probably about the same. > It seems like this could lead to surprising behavior if > the user modifies the definition of the operator class. Right now, operator classes can't be modified in any meaningful way. Am I missing something? > 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? Are you suggesting I change the error output, or reorganize the code to try to reuse BuildIndexValueDescription, or both? Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: