Re: WIP: generalized index constraints

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: tomas(at)tuxteam(dot)de
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: generalized index constraints
Date: 2009-09-16 16:45:52
Message-ID: 1253119552.24770.203.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2009-09-16 at 15:11 +0200, tomas(at)tuxteam(dot)de wrote:
> One question: does the operator have to be reflexive? I.e. "A op A holds
> for all A"?

I don't think that reflexivity is a strict requirement. You could make
this a constraint over a boolean attribute such that false conflicts
with true and true conflicts with false. That would mean that your table
would have to consist of either all false or all true.

> I am thinking "proximity" or as you state above "similarity". May be
> this is a good metaphor, leading to a good name.

That's an interesting idea: "proximity constraint". I like it because
(a) "proximity" might reasonably be considered a more general form of
the word "unique", which might satisfy Peter's argument; (b) it conveys
the use case; and (c) it sounds good.

There are a couple bizarre cases where "proximity" doesn't quite fit,
like my boolean example above, but I'm OK with that.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-09-16 17:05:43 Re: Linux LSB init script
Previous Message Steve Prentice 2009-09-16 16:19:25 Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]