| From: | Matteo Beccati <php(at)beccati(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Christoph Berg <cb(at)df7cb(dot)de>, Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>, Dave Page <dpage(at)postgresql(dot)org>, Jakob Egger <jakob(at)eggerapps(dot)at>, Palle Girgensohn <girgen(at)pingpong(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready) |
| Date: | 2014-05-23 15:28:42 |
| Message-ID: | 537F692A.5090504@beccati.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23/05/2014 10:05, Matteo Beccati wrote:
> You can find the code here:
> https://github.com/mbeccati/uuid # NetBSD variant
> https://github.com/mbeccati/uuid/tree/linux # Ubuntu variant
>
> For now, I've forked just RhodiumToad's uuid-freebsd extension, but I've
> made sure make works fine when cloned in the contrib folder.
>
> * Both the variants use a copy of pgcrypto md5/sha1 implementations to
> generate v3 and v5 UUIDs as porting is much easier than trying to use
> the system provided ones, if any.
> * I've fixed a bug in v3/v5 generation wrt endianness as the results I
> was getting didn't match the RFC.
> * The code is PoC quality and I haven't touched the docs/readme yet.
And here's my last effort w/ autoconf support:
https://github.com/mbeccati/postgres/compare/postgres:master...master
It's surely far from perfect, but maybe closer to something that can be
considered as a replacement for OSSP.
Especially I'm not that happy about the #ifdefs cluttering the code and
AC_SEARCH_LIB putting libuuid in $LIBS. Any suggestion?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2014-05-23 16:31:04 | Re: Wait free LW_SHARED acquisition - v0.2 |
| Previous Message | Tom Lane | 2014-05-23 15:13:11 | Re: Allowing join removals for more join types |