On Mon, Nov 28, 2016 at 4:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > What I would suggest is that you forget the union hack and just use > memcmp in all the comparison functions. It's not likely to be worth > the trouble to try to get those calls to be safely aligned. The > only place where you need go to any trouble is in uuid_parts_distance, > which could be redesigned to memcpy a not-necessarily-aligned source > into a local uint64[2] array and then byte-swap if needed.
Done. I only have one architecture to test on (Linux, Intel x86_64) so
I must defer to others in this regard.
> I don't entirely see the point of making pg_uuid_t an opaque struct when
> the only interesting thing about it, namely UUID_LEN, is exposed anyway.
> So my inclination would be to just do
>
> typedef struct pg_uuid_t
> {
> unsigned char data[UUID_LEN];
> } pg_uuid_t;
>
> in uuid.h and forget the idea of it being opaque.
Done.
> Also, the patch could be made a good deal smaller (and easier to review)
> in the wake of commit 40b449ae8: you no longer need to convert
> btree_gist--1.2.sql into btree_gist--1.3.sql, just leave it alone and add
> btree_gist--1.2--1.3.sql. That way we don't have to worry about whether
> the upgrade script matches the change in the base script.
Done.
-- Chris
btree_gist_uuid_8.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
