On Wed, Nov 18, 2009 at 9:00 AM, Jeff Davis <pg...@j-davis.com> wrote: > 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 sets off a red flag for me any time I see code that asks for A from the user and then actually stores B under the hood, for fear that the relationship that A and B might change. However... >> 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? ...poking at it, I have to agree that at least as things stand right now, I can't find a way to break it. Not sure if it's future-proof. >> 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? I was thinking maybe you call BuildIndexValueDescription twice and make the error message say something like <output of first call> conflicts with <output of second call>. One other thing I noticed tonight while poking at this. If I install contrib/citext, I can do this: create table test (a citext, exclude using hash (a with =)); But if I install contrib/intarray, I can't do this: create table test (a int4[], exclude using gist (a with =)); ERROR: operator does not exist: integer[] = integer[] Not sure if I'm doing something wrong, or if this is a limitation of the design, or if it's a bug, but it seems strange. I'm guessing it's because intarray uses the anyarray operator rather than a dedicated operator for int[], but it seems like that ought to work. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
