Re: operator exclusion constraints

On Wed, 2009-11-25 at 09:02 -0500, Robert Haas wrote:
> I disagree wholeheartedly. :-) My ideal error message is something like:
>
> DETAIL: (a, b, c)=(1, 2, 3) conflicts with (a, b, c)=(4, 5, 6)
>
> In particular, I think it's very important that we only emit the
> columns which are part of the operator exclusion constraints, and NOT
> all the columns of the tuple. The entire tuple could be very large -
> one of the columns not involved in the constraint could be a 4K block
> of text, for example, and spitting that out only obscures the real
> source of the problem. You could argue that one of the columns
> involved in the constraint could be a 4K block text, too, but in
> practice I think the constraint columns are likely to be short nine
> times out of ten. The equals sign is equating the column names to the
> column values, not the values to each other, so I don't see that as
> confusing.

Ok, fair enough. But how do you feel about:
(a: 1, b: 2, c: 3)
as a tuple representation instead? I think it's closer to the way people
expect a tuple to be represented. I can change it in one place so that
the unique violations are reported that way, as well (as long as there
are no objections).

It still doesn't contain the operators, but they can look at the
constraint definition for that.

> My operator-class-fu is insufficient to render judgment on this point.
> I think the thing to do is look at a bunch of non-built-in opclasses
> and check for POLA violations.

Ok, I'll consider this more.

Regards,
Jeff Davis