Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On 22/05/2014 21:55, Matteo Beccati wrote: On 22/05/2014 17:07, Tom Lane wrote: Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. This sounds an easy enough task to try and submit a patch, if I'm able to allocate enough time to work on it. I have successfully compiled the extension on a NetBSD box using a slightly modified version of Palle's patch. I have a few doubts though: - should we keep the extension name? If not, what would be the plan? - the patch also uses BSD's own md5 and sha1 implementations: for md5 I should be able to use pg's own core version, but I'm not sure about sha1, as it lives in pgcrypto. Any suggestion? Maybe I've put the cart before the horse a little bit ;) Anyway, BSD and Linux UUID implementations are slightly different, but I was able to get two variants of the extension to compile on NetBSD and Ubuntu. I don't have the necessary autoconf-fu to merge them together though, and to make sure that they compile on the various bsd/linux flavours. 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. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
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=348732view=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
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
Robert Haas robertmh...@gmail.com writes: On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: 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. Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On 22/05/2014 17:07, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: 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. Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. This sounds an easy enough task to try and submit a patch, if I'm able to allocate enough time to work on it. I have successfully compiled the extension on a NetBSD box using a slightly modified version of Palle's patch. I have a few doubts though: - should we keep the extension name? If not, what would be the plan? - the patch also uses BSD's own md5 and sha1 implementations: for md5 I should be able to use pg's own core version, but I'm not sure about sha1, as it lives in pgcrypto. Any suggestion? Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On Thu, May 22, 2014 at 11:07 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sun, May 18, 2014 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote: 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. Well, *I* don't want to do that work. I was hoping to find a volunteer, but the silence has been notable. I think deprecation is the next step. If we can't get it fixed up, I think we should remove it outright. If we merely deprecate it, then either people will still be trying to build and package it (in which case we haven't solved any problem), or we'll never get around to really removing it, or both. -- 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
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
On 5/18/14, 12:28 AM, Tom Lane wrote: 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. I was going to propose based on earlier discussion that we would stick a deprecation notice on uuid-ossp and leave it at that. Between pgcrypto and https://github.com/petere/pglibuuid, there are other options available. Writing wrapper functions for backward compatibility is trivial for users. A bigger question is whether there are any user-visible functional incompatibilities introduced by depending on either of those libraries instead of OSSP uuid. Some research would be needed. You might need to make sure your random sources are set up appropriately, and that might differ between libraries. And libuuid recommends the use of the uuidd daemon in some circumstances. These are arguments, in my mind, for not providing compatibility wrappers by default, so that these issues don't get hidden. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)
Christoph Berg c...@df7cb.de writes:
[redirecting to -hackers]
Re: Tom Lane 2014-05-15 31008.1400180...@sss.pgh.pa.us
Sandeep Thakkar sandeep.thak...@enterprisedb.com writes:
Yes, Jakob is right. On 9.4, we had to patch configure script along with
uuid-ossp.c to resolve the uuid issue.
I think we need to discuss this on the open pgsql-hackers list.
It seems like we have to either
(1) hack both configure and uuid-ossp.c to work around the issue
(2) do something more radical, like adopt Palle's patch to use the
BSD uuid functions.
Now, (2) sounds a bit scary for a post-beta1 change, but on the other hand
we know that ossp-uuid is a train wreck in progress. Maybe it's time
to do something about it. But that's got to be debated on -hackers not
here.
Fwiw, libossp-uuid is the only non-trivial dependency of
postgresql*.{deb,rpm} - I've been to trainings at customer sites more
than once where we just had a preinstalled Linux machine with no
internet and a set of PostgreSQL packages that needed dpkg
--force-depends or rpm --nodeps to install just because the -contrib
package needs that lib.
So if we got rid of that dependency, life might become a bit easier
also in that setting.
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=348732view=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.
A bigger question is whether there are any user-visible functional
incompatibilities introduced by depending on either of those libraries
instead of OSSP uuid. Some research would be needed.
It's not exactly appetizing to consider fooling around with such changes
post-beta1. But on the other hand, OSSP uuid *is* a train wreck in
progress, and remaining dependent on it for another release cycle is not
exactly appetizing either.
Comments? Is anybody feeling motivated to do the legwork on this?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
