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:01:04Z
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:
> The fly in the ointment for strxfrm() adoption may be the need to be
> consistent with this earlier behaviour:

>     if strcoll claims two strings are equal, check it with strcmp, and
>     sort according to strcmp if not identical.

> I'm not sure I agree with this decision; why should we presume to know
> better than the glibc locale what constitutes equality?

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.  My recollection is that there were
some other problems as well, but I'm too lazy to search the archives
for you.

> It's seems very likely that the main
> one was the then-need to guard against poor quality qsort()
> implementations that went quadratic in the face of lots of duplicates,

No, I don't recall that that had anything to do with it.

			regards, tom lane