Re: operator exclusion constraints
От | Jeff Davis |
---|---|
Тема | Re: operator exclusion constraints |
Дата | |
Msg-id | 1259137393.19289.245.camel@jdavis обсуждение исходный текст |
Ответ на | Re: operator exclusion constraints (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: operator exclusion constraints
|
Список | pgsql-hackers |
On Thu, 2009-11-19 at 22:55 -0500, Robert Haas wrote: > > 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... Still not addressed because it touches a bit more code (including the catalogs). I basically agree, however, so I'll take care of this soon. > 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>. Do you really think that's a better error message, or are you just trying to re-use similar code? Let's start from how the error message should read, and then see if we can re-use some code to make it look that way. It's one of the most visible aspects of the feature, and it needs to be reasonably concise and understandable in the simple case, but contain all of the necessary information. I think it's better to avoid the "=" when describing the conflict. I tend to read it as "equals" even though it's just punctuation in this case, so it would be distracting. I could change it to a colon, I suppose. > create table test (a int4[], exclude using gist (a with =)); > ERROR: operator does not exist: integer[] = integer[] Thanks, fixed. I am now using compatible_oper_opid(), which will find any operators that don't require binary-incompatible coercion of the operands. Do you think there's any reason to support binary-incompatible coercion of the operands? I can't think of a single use case, and if you really need to, you can coerce the types explicitly in the expression. Changes in attached patch: * use compatible_oper_opid() to find operator from name * Add new SQLSTATE 23P01 for the operator exclusion constraint error, so that applications can more easily distinguish it from other constraint violations. Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: