Re: Fixing row comparison semantics

Поиск
Список
Период
Сортировка
От Bruno Wolff III
Тема Re: Fixing row comparison semantics
Дата
Msg-id 20051228192820.GA26331@wolff.to
обсуждение исходный текст
Ответ на Fixing row comparison semantics  (Gregory Maxwell <gmaxwell@gmail.com>)
Список pgsql-hackers
On Mon, Dec 26, 2005 at 15:12:48 -0500, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On 12/26/05, Pavel Stehule <pavel.stehule@hotmail.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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: plperl vs LC_COLLATE (was Re: Possible savepoint bug)
Следующее
От: "Rocco Altier"
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Mention "table" in "violates foreign key constraint" message that