Re: operator exclusion constraints - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: operator exclusion constraints
Date
Msg-id 1258552809.19351.25.camel@jdavis-laptop
Whole thread Raw
In response to Re: operator exclusion constraints  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: operator exclusion constraints
Re: operator exclusion constraints
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: UTF8 with BOM support in psql
Next
From: Peter Eisentraut
Date:
Subject: Re: UTF8 with BOM support in psql