On Sun, May 18, 2014 at 12:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I was intending to draft something more self-contained to present to > -hackers, but since this is where we're at ... the quoted material > omits a couple of important points: > > (1) People had been working around uuid-ossp's issues on OS X by > patching a "#define _XOPEN_SOURCE" into contrib/uuid-ossp/uuid-ossp.c. > As of 9.4 this is no longer sufficient because we upgraded to autoconf > 2.69, which uses stricter testing for include-file validity than older > versions did. The test to see if uuid.h is available therefore fails, > unless that #define is also patched into the configure script. In any > case "#define _XOPEN_SOURCE" has enough potential implications that > this doesn't seem like a very recommendable solution. > > (2) "Palle's patch" mentioned above can be seen here: > http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/files/patch-contrib-uuid?revision=348732&view=markup > Basically it jacks up contrib/uuid-ossp and rolls the BSD uuid functions > underneath. It looks like this is based on work by Andrew Gierth. > > So, having seen that proof-of-concept, I'm wondering if we shouldn't make > an effort to support contrib/uuid-ossp with a choice of UUID libraries > underneath it. There is a non-OSSP set of UUID library functions > available on Linux ("libuuid" from util-linux-ng). I don't know whether > that's at all compatible with the BSD functions, but even if it's not, > presumably a shim for it wouldn't be much larger than the BSD patch.
Well, if you want to do the work, I'm fine with that. But if you want to just shoot uuid-ossp in the head, I'm fine with that, too. As Peter says, perfectly reasonable alternatives are available. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
