Re: GiST support for UUIDs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chris Bandy <bandy.chris@gmail.com>
Cc: Adam Brusselback <adambrusselback@gmail.com>,
Michael Paquier <michael.paquier@gmail.com>,
Paul A Jungwirth <pj@illuminatedcomputing.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-11-29T19:13:57Z
Lists: pgsql-hackers
I wrote: > I'm kind of inclined to change uuid_parts_distance to just convert > a given pg_uuid_t to "double" and then apply penalty_num(), as is > done in gbt_macad_penalty. Pushed with that change and some other mostly-cosmetic tweaking. One not too cosmetic fix was that gbt_uuid_union was declared with the wrong return type. That's probably mostly harmless given that core GiST pays little attention to the declared signatures of the support functions, but it's not a good thing. This would've been caught if anyone had thought to run the amvalidate functions on the updated extension. I think I will go and put a call to that into the regression tests of all the contrib modules that define new opclasses. regards, tom lane
Commits
-
Test all contrib-created operator classes with amvalidate.
- ade49c605f1d 10.0 landed
-
Add uuid to the set of types supported by contrib/btree_gist.
- 11da83a0e70d 10.0 landed
-
Allow CREATE EXTENSION to follow extension update paths.
- 40b449ae84dc 10.0 cited