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-01T02:55:01Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> I think this takes care of adding not only the infrastructure but
> support for all the core data types, but I'm not quite sure how to
> handle upgrading types in contrib.  It looks like citext, hstore, and
> several data types provided by isn have hash opclasses, and I think
> that there's no syntax for adding a support function to an existing
> opclass.  We could add that, but I'm not sure how safe it would be.

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.

			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