Horton

Re: sortsupport for text

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Greg Stark <stark@mit.edu>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-06-17T16:50:09Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Adjust string comparison so that only bitwise-equal strings are considered

  2. Add operator strategy and comparison-value datatype fields to ScanKey.

Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 17 June 2012 17:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The killer reason why it must be like that is that you can't use hash
>> methods on text if text equality is some unknown condition subtly
>> different from bitwise equality.

> Fair enough, but I doubt that we need to revert the changes made in
> this commit to texteq in addition to the changes I'd like to see in
> order to be semantically self-consistent. That is because there is
> often a distinction made between equality and equivalence, and we
> could adopt this distinction.

How exactly do you plan to shoehorn that into SQL?  You could invent
some nonstandard "equivalence" operator I suppose, but what will be the
value?  We aren't going to set things up in such a way that we can't
use hash join or hash aggregation in queries that use the regular "="
operator.  IMO there just aren't going to be enough people who care to
use a non-default operator.

			regards, tom lane