Thread: ossp-uuid Contrib Patch
Hackers, I ran into an issue building 9.2 with the OSSP UUID module today. A bit of Googling and I found that the MacPorts guys raninto the same issue a few weeks ago. Their discussion: https://trac.macports.org/ticket/35153 And the fix: https://trac.macports.org/browser/trunk/dports/databases/postgresql91/files/postgresql-uuid-ossp.patch?rev=96142 So should we do this in core, too? Oh, I see Tom already commented on it here: http://archives.postgresql.org/pgsql-general/2012-07/msg00656.php I had installed 9.2rc1 a few weeks ago, but since then I upgraded to Mountain Lion. I suspect that is what mucked up theunistd.h ordering issue. The patch: diff --git a/contrib/uuid-ossp/uuid-ossp.c b/contrib/uuid-ossp/uuid-ossp.c index d4fc62b..62b28ca 100644 --- a/contrib/uuid-ossp/uuid-ossp.c +++ b/contrib/uuid-ossp/uuid-ossp.c @@ -9,6 +9,7 @@ *------------------------------------------------------------------------- */ +#define _XOPEN_SOURCE#include "postgres.h"#include "fmgr.h"#include "utils/builtins.h" Best, David
"David E. Wheeler" <david@justatheory.com> writes:
> I ran into an issue building 9.2 with the OSSP UUID module today. A bit of Googling and I found that the MacPorts
guysran into the same issue a few weeks ago. Their discussion:
The long and the short of it is that the OSSP guys need to fix their
code. I'm not excited about kluges like
> +#define _XOPEN_SOURCE
which might band-aid around their mistake, but at what price? We have
no idea what side-effects that will have. It would not be unlikely
for that to result in an ossp-uuid.so that is subtly incompatible with
the core backend. (We've seen such effects in the past, though I'm too
lazy to trawl the archives for examples right now.)
regards, tom lane
On Sep 10, 2012, at 4:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The long and the short of it is that the OSSP guys need to fix their > code. I'm not excited about kluges like > >> +#define _XOPEN_SOURCE > > which might band-aid around their mistake, but at what price? We have > no idea what side-effects that will have. It would not be unlikely > for that to result in an ossp-uuid.so that is subtly incompatible with > the core backend. (We've seen such effects in the past, though I'm too > lazy to trawl the archives for examples right now.) Well given that OSSP seems to be abandon ware (no activity since July 2008), it might be time to dump it in favor of somethingelse. Best, David
"David E. Wheeler" <david@justatheory.com> writes:
> Well given that OSSP seems to be abandon ware (no activity since July 2008), it might be time to dump it in favor of
somethingelse.
Yeah, maybe. It doesn't even seem to be the "standard" implementation
on Linux or Mac. A bit of research says that Theodore Ts'o's libuuid
is what comes native with the OS on those platforms. No idea whether
the functionality is equivalent, though.
regards, tom lane
On Mon, 2012-09-10 at 16:23 -0700, David E. Wheeler wrote: > Well given that OSSP seems to be abandon ware (no activity since July > 2008), it might be time to dump it in favor of something else. Are there any outstanding issues that would require an update?
On Mon, 2012-09-10 at 20:15 -0400, Tom Lane wrote: > "David E. Wheeler" <david@justatheory.com> writes: > > Well given that OSSP seems to be abandon ware (no activity since July 2008), it might be time to dump it in favor ofsomething else. > > Yeah, maybe. It doesn't even seem to be the "standard" implementation > on Linux or Mac. A bit of research says that Theodore Ts'o's libuuid > is what comes native with the OS on those platforms. No idea whether > the functionality is equivalent, though. They have different interfaces that would also affect the exposed SQL interfaces. We could provide two different extensions, wrapping each library.
On Sep 10, 2012, at 6:01 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >> Well given that OSSP seems to be abandon ware (no activity since July >> 2008), it might be time to dump it in favor of something else. > > Are there any outstanding issues that would require an update? Many. Look at all the issues with the Subsys "uuid" here: http://cvs.ossp.org/rptview?rn=1&order_by=7&order_dir=ASC Best, David
On Sep 10, 2012, at 6:05 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >> Yeah, maybe. It doesn't even seem to be the "standard" implementation >> on Linux or Mac. A bit of research says that Theodore Ts'o's libuuid >> is what comes native with the OS on those platforms. No idea whether >> the functionality is equivalent, though. > > They have different interfaces that would also affect the exposed SQL > interfaces. We could provide two different extensions, wrapping each > library. Yes, I think the question becomes how much pg wants to depend on abandonware for its contrib extensions. Best, David
On Mon, Sep 10, 2012 at 04:23:00PM -0700, David E. Wheeler wrote: > Well given that OSSP seems to be abandon ware (no activity since July > 2008), it might be time to dump it in favor of something else. Perhaps this would be a good time to bring up my uuid code again. I've got a module for uuid support for postgres. Originally written for 8.4 but I've kept it updated. It's available at https://pd.if.org/git/uuid.git and for anonymous git cloning git clone https://pd.f.org/git/uuid The install directions are perhaps a bit lacking, but after the git checkout: cd uuid make cd postgres make sudo make install psql -c 'create extension pduuid' Installing to different schemas is supported also. The postgres/README file describes the supported features. Briefly, my code supports uuid generation of version 1, 3, 4, and 5 uuids, casting to and from numeric, bit string, and bytea values, and provides a uuid_recent() function to get the most recent uuid generated in that backend. The code is entirely in the public domain. At one point, it compiled on Windows and MacOS, but I haven't tested that recently. I don't think I have changed anything that would affect compiling on those platforms. IIRC, the only platform dependent code is in figuring out a local mac address and a sub-second timestamp. Comments or suggestions welcome. -- nw