Re: WIP: generalized index constraints - Mailing list pgsql-hackers

From tomas@tuxteam.de
Subject Re: WIP: generalized index constraints
Date
Msg-id 20090916194044.GB21600@tomas
Whole thread Raw
In response to Re: WIP: generalized index constraints  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Sep 16, 2009 at 09:45:52AM -0700, Jeff Davis wrote:
> On Wed, 2009-09-16 at 15:11 +0200, tomas@tuxteam.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.

Let me see whether I've understood this: more in general, op could be
"not equal" -- i.e. <>. Then, once one value was inserted into the
column, all other values would have to be equal.

[...]

> 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.

Yes, "riding" on this geometric metaphor (distance), I was trying to
visualize relations which are symmetric but not refexive and came up
with things like
 "point X is at least d1 far, at most d2 far from Y"

i.e. Y are all points which are whithin a ring centered on Y, with inner
radius d1 and outer radius d2. Special cases would be d1=0, d2>0 (that's
conventional proximity) -- but there are weirder cases, as your example
above (d2 possibly infinite, d1 small, giving a "punctured space").

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

Hmmm.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKsT88Bcgs9XrR2kYRAlmcAJ9+rP7AkimXRPoKGaBoJkthX2LzggCfTWst
KF/XMRouhlEbQcORaeoIbc0=
=BBEF
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
Next
From: Michael Glaesemann
Date:
Subject: Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]