From: | Chris Bandy <bandy(dot)chris(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Adam Brusselback <adambrusselback(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GiST support for UUIDs |
Date: | 2016-11-29 05:31:51 |
Message-ID: | CAMDg7WzsR0FRbZwu97a92GZvBXuPOheSY4mV3m=yjRMquV5pvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 28, 2016 at 4:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
Attachment | Content-Type | Size |
---|---|---|
btree_gist_uuid_8.patch | application/octet-stream | 37.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-11-29 05:39:47 | Re: Tackling JsonPath support |
Previous Message | Pavel Stehule | 2016-11-29 05:28:17 | Re: Tackling JsonPath support |