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 ran into the same issue a few weeks ago. Their discussion:
https://trac.macports.org/ticket/35153
And the fix:
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 the unistd.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 guys ran 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 something else.
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 something 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.
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 of something 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
Attachments:
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
Attachments:
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