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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: UTF8 with BOM support in psql
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: UTF8 with BOM support in psql