Skip site navigation (1) Skip section navigation (2)

Re: Fixing row comparison semantics

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Gregory Maxwell <gmaxwell(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixing row comparison semantics
Date: 2005-12-28 19:28:20
Message-ID: 20051228192820.GA26331@wolff.to (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Dec 26, 2005 at 15:12:48 -0500,
  Gregory Maxwell <gmaxwell(at)gmail(dot)com> wrote:
> On 12/26/05, Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com> wrote:
> > (1,1) <* (1,2) = true
> > (1,2) <* (2,1) is NULL
> > (2,3) <* (1,2) = false
> >
> > it's usefull for multicriterial optimalisation
> 
> This is indeed a sane and useful function which should be adopted by
> the SQL standard.. in postgresql this would easily enough be
> implemented as a user function so I'm not sure we need special support
> for it.
> 
> The idea is that in a multidimension comparison you can only sometimes
> say when one tuple is strictly less than (or greater than) another
> because differing dimensions are incomparable.  So, like his example,
> we can not say if (1,2) is lesser or greater than (2,1) because saying
> so would require some priority of the dimensions which may not be
> known or may not exist, it is only clear that they are not equal..

That's normally called a partial order. From CS classes, I don't remember
ever seeing < and > combined that way. Normally you just looked at whether
or not < was true or whether or not > was true.
Is it common in practice for people to want the answer to both of these at
once? Also if you are really dealing with <= and >= (as your example above
seems to imply), then there are 4 possible states (the new one being a = b)
and you can't represent that with just 3 possible results.

In response to

pgsql-hackers by date

Next:From: Rocco AltierDate: 2005-12-28 20:21:42
Subject: Re: [COMMITTERS] pgsql: Mention "table" in "violates foreign key constraint" message that
Previous:From: Andrew DunstanDate: 2005-12-28 17:33:33
Subject: Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group