Horton

Re: sortsupport for text

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <stark@mit.edu>, PG Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-06-17T18:48:40Z
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.

On Jun 17, 2012 5:50 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>
> Peter Geoghegan <peter@2ndquadrant.com> writes:
> > On 17 June 2012 17:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Right, most people won't care. You may or may not want a new
Operator for equivalency. The regular operator for equality doesn't have to
and shouldn't change. It is both useful and conceptually clean to not
guarantee that a compator can be relied upon to indicate equality and not
just equivalency.