From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | amul sul <sulamul(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Joe Conway <mail(at)joeconway(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Subject: | Re: Hash Functions |
Date: | 2017-09-01 02:31:25 |
Message-ID: | CA+TgmobWp_Q3k=-+LXU30nNJ74as1LPB0M-mWqOGmv8A7KANAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 31, 2017 at 8:40 AM, amul sul <sulamul(at)gmail(dot)com> wrote:
> Fixed in the attached version.
I fixed these up a bit and committed them. Thanks.
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.
TBH, I really don't care much about fixing isn, but it seems like
fixing citext and hstore would be worthwhile.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-01 02:55:01 | Re: Hash Functions |
Previous Message | Bruce Momjian | 2017-09-01 02:30:40 | Re: Authentication mechanisms categorization |