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

Re: Removing SORTFUNC_LT/REVLT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Removing SORTFUNC_LT/REVLT
Date: 2005-12-31 19:54:18
Message-ID: 20978.1136058858@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Sat, Dec 31, 2005 at 12:58:19AM -0500, Greg Stark wrote:
>>  Two things are either the same or they aren't, and that can't change
>> based on context.

> So someone who wants a case-insensetive search actually doesn't want
> "Foo" to equal "foo"?

That nice simple worldview falls down in other areas as well.  An
example is zero and minus zero in IEEE math: they are equal for some
purposes but not others.  I think you really have to say that equality
is defined with respect to a particular datatype and a particular set
of operators.

The example of case-insensitive sorting suggests that we need to assume
that sort comparison functions can make finer-grained comparisons than
the associated "equals" operator does.  The current infrastructure
forces these to be exactly the same, but as long as we're busy
reinventing stuff, we could have two comparison functions associated
with a btree opclass: one that mimics the operators' behavior and one
that makes finer-grained comparisons and defines the actual sort order.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2005-12-31 20:56:30
Subject: Re: Removing SORTFUNC_LT/REVLT
Previous:From: Rod TaylorDate: 2005-12-31 19:48:48
Subject: Re: EINTR error in SunOS

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