Horton

Re: Hash Functions

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

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: amul sul <sulamul@gmail.com>, Andres Freund <andres@anarazel.de>, Joe Conway <mail@joeconway.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Jeff Davis <pgsql@j-davis.com>, Yugo Nagata <nagata@sraoss.co.jp>
Date: 2017-09-01T03:07:09Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 31, 2017 at 10:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ALTER OPERATOR FAMILY ADD FUNCTION ... ?
>> 
>> That would result in the functions being considered "loose" in the
>> family rather than bound into an operator class.  I think that's
>> actually the right thing, because they shouldn't be considered
>> to be required.

> But wouldn't that result in a different effect than the core data type
> changes I just did?

Possibly --- I have not read that patch.  But considering that all core
functions are pinned anyway, it doesn't seem like it much matters whether
we consider them to be loosely or tightly bound to opclasses.  That
should only matter if one tries to drop the function.

			regards, tom lane

Commits

  1. Introduce 64-bit hash functions with a 64-bit seed.

  2. Create a "sort support" interface API for faster sorting.

  3. Add seven kanji characters defined in the Windows 950 codepage to our