Re: [HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Alvaro Herrera]

高增琦 wrote:
> : (
> 
> still don't know how to build ossp-uuid on windows with MSVC.
> Saito san's patch doesn't fix all errors during compiling...

I don't understand why you want to build that specific module on Windows.
Doesn't Windows have its own UUID generator that you can access, using a
smaller extension?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[高增琦]

: (

still don't know how to build ossp-uuid on windows with MSVC.
Saito san's patch doesn't fix all errors during compiling...

I will try to combine this patch and the win32build on sf.net

Same questions again:
How was the dll file in the community binary built?
How to avoid duplicate UUIDs then?

thanks a lot.

2013-11-05 2:49 GMT+08:00 Christopher Browne :

> On Thu, Oct 31, 2013 at 3:42 PM, Robert Haas 
> wrote:
> > On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin 
> wrote:
> >> I think using /dev/urandom directly would be surprising. At least it
> would
> >> have probably have taken me a while to figure out what was depleting the
> >> entropy pool here.
> >
> > Perhaps so; a bigger problem IMHO is that it's not portable. I think
> > the only way to solve this problem is to import (or have an option to
> > link with) a strong, sophisticated PRNG with much larger internal
> > state than pg_lrand48, which uses precisely 48 bits of internal state.
> > For this kind of thing, I'm fairly sure that we need something with
> > at least 128 bits of internal state (as wide as the random value we
> > want to generate) and I suspect it might be advantageous to have
> > something a whole lot wider, maybe a few kB.
>
> I mentioned the notion of building an entropy pool, into which one might
> add various sorts of random inputs, under separate cover...
>
> The last time I had need of a rather non-repeating RNG, I went with
> a Fibonacci-based one, namely Mersenne Twister...
>
> 
>
> The sample has 624 integers (presumably that means 624x32 bits) as
> its internal state. Apparently not terribly suitable for cryptographic
> purposes,
> but definitely highly non-repetitive, which is what we're notably
> worried about for UUIDs.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
>



-- 
GaoZengqi
pgf...@gmail.com
zengqi...@gmail.com

Re: [HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Christopher Browne]

On Thu, Oct 31, 2013 at 3:42 PM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin gham...@isc.upenn.edu
wrote:
 I think using /dev/urandom directly would be surprising. At least it
would
 have probably have taken me a while to figure out what was depleting the
 entropy pool here.

 Perhaps so; a bigger problem IMHO is that it's not portable. I think
 the only way to solve this problem is to import (or have an option to
 link with) a strong, sophisticated PRNG with much larger internal
 state than pg_lrand48, which uses precisely 48 bits of internal state.
 For this kind of thing, I'm fairly sure that we need something with
 at least 128 bits of internal state (as wide as the random value we
 want to generate) and I suspect it might be advantageous to have
 something a whole lot wider, maybe a few kB.

I mentioned the notion of building an entropy pool, into which one might
add various sorts of random inputs, under separate cover...

The last time I had need of a rather non-repeating RNG, I went with
a Fibonacci-based one, namely Mersenne Twister...

http://en.wikipedia.org/wiki/Mersenne_twister

The sample has 624 integers (presumably that means 624x32 bits) as
its internal state. Apparently not terribly suitable for cryptographic
purposes,
but definitely highly non-repetitive, which is what we're notably
worried about for UUIDs.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, How would the Lone Ranger handle this?

Re: [HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Robert Haas]

On Wed, Oct 30, 2013 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 MauMau maumau...@gmail.com writes:
 From: Tom Lane t...@sss.pgh.pa.us
 Yeah, but what shall we replace it with?  And can we preserve the
 API contrib/uuid-ossp offers?  (Maybe we shouldn't even try, but
 just deprecate that module and start fresh.)

 Would it be welcomed in this community if a patch for built-in UUID
 generation functions are provided?

 Based on what?  The reason we've held this code at arms length (in a
 contrib module) is exactly that we weren't too satisfied with the
 portability or adequacy of the generation methods.  Moving the functions
 into core doesn't do anything to make that better; rather, it raises the
 portability bar even higher, as well as making it almost impossible to
 contemplate further API changes.

 Note the lack of enthusiasm for taking on maintainership of the OSSP
 code.  Pushing it into core would mean that we're buying into that
 maintainership, hook line and sinker.  I don't think that such a
 proposal would fly.

ISTM that the biggest problem is that we don't have a random number
generator which generates enough bits of randomness to implement
uuid_generate_v3.  I think relatively few people would cry if we
didn't support uuid_generate_v1(), and the others all look simple
enough, provided there's somewhere to get lots of random bits.

On Linux, it seems like we could get those bits from /dev/urandom,
though I'm not sure how efficient that would be for the case where
many UUIDs are being generated at once.  But that wouldn't be very
portable.  It's tempting to think that we'd need a PRNG that generates
wider values, for which we might find other application also.  But I'm
not volunteering to be the one to create such a thing.

-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Andres Freund]

On 2013-10-31 08:22:14 -0400, Robert Haas wrote:
 On Wed, Oct 30, 2013 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  MauMau maumau...@gmail.com writes:
  Note the lack of enthusiasm for taking on maintainership of the OSSP
  code.  Pushing it into core would mean that we're buying into that
  maintainership, hook line and sinker.  I don't think that such a
  proposal would fly.
 
 ISTM that the biggest problem is that we don't have a random number
 generator which generates enough bits of randomness to implement
 uuid_generate_v3.  I think relatively few people would cry if we
 didn't support uuid_generate_v1(), and the others all look simple
 enough, provided there's somewhere to get lots of random bits.

Yea, I think restricting ourselves to v3/4/5 is a sensible thing.

 On Linux, it seems like we could get those bits from /dev/urandom,
 though I'm not sure how efficient that would be for the case where
 many UUIDs are being generated at once.  But that wouldn't be very
 portable.  It's tempting to think that we'd need a PRNG that generates
 wider values, for which we might find other application also.  But I'm
 not volunteering to be the one to create such a thing.

We could copy ossp's implementation, it's just 200 lines and seems to
have a compatible license.
util-linux's libuuid is BSD as well and seems to have some windows
support although that's by memory.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[MauMau]

From: Robert Haas robertmh...@gmail.com

ISTM that the biggest problem is that we don't have a random number
generator which generates enough bits of randomness to implement
uuid_generate_v3.  I think relatively few people would cry if we
didn't support uuid_generate_v1(), and the others all look simple
enough, provided there's somewhere to get lots of random bits.

On Linux, it seems like we could get those bits from /dev/urandom,
though I'm not sure how efficient that would be for the case where
many UUIDs are being generated at once.  But that wouldn't be very
portable.  It's tempting to think that we'd need a PRNG that generates
wider values, for which we might find other application also.  But I'm
not volunteering to be the one to create such a thing.


OpenSSL provides rand_bytes() which generates random bytes of any length. 
It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of 
Microsoft on Windows.


Regards
MauMau




--
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Peter Eisentraut]

On 10/30/13, 12:43 PM, Tom Lane wrote:
 Alvaro Herrera alvhe...@2ndquadrant.com writes:
 At this point, I think we need to consider ossp-uuid as dead code.
 
 Yeah, but what shall we replace it with?

One possibility:

https://github.com/petere/pglibuuid

Not sure whether that has a chance of working on Windows.


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Garick Hamlin]

On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
 From: Robert Haas robertmh...@gmail.com
 ISTM that the biggest problem is that we don't have a random number
 generator which generates enough bits of randomness to implement
 uuid_generate_v3.  I think relatively few people would cry if we
 didn't support uuid_generate_v1(), and the others all look simple
 enough, provided there's somewhere to get lots of random bits.

 On Linux, it seems like we could get those bits from /dev/urandom,
 though I'm not sure how efficient that would be for the case where
 many UUIDs are being generated at once.  But that wouldn't be very
 portable.  It's tempting to think that we'd need a PRNG that generates
 wider values, for which we might find other application also.  But I'm
 not volunteering to be the one to create such a thing.

 OpenSSL provides rand_bytes() which generates random bytes of any length. 
 It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of  
 Microsoft on Windows.

What about using a cipher here as the PRNG? It seems like using openssl
rand_bytes() to seed aes in ctr would work ok without starving the system of
entropy when making a lot of uuids.

Garick


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Robert Haas]

On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin gham...@isc.upenn.edu wrote:
 On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
 From: Robert Haas robertmh...@gmail.com
 ISTM that the biggest problem is that we don't have a random number
 generator which generates enough bits of randomness to implement
 uuid_generate_v3.  I think relatively few people would cry if we
 didn't support uuid_generate_v1(), and the others all look simple
 enough, provided there's somewhere to get lots of random bits.

 On Linux, it seems like we could get those bits from /dev/urandom,
 though I'm not sure how efficient that would be for the case where
 many UUIDs are being generated at once.  But that wouldn't be very
 portable.  It's tempting to think that we'd need a PRNG that generates
 wider values, for which we might find other application also.  But I'm
 not volunteering to be the one to create such a thing.

 OpenSSL provides rand_bytes() which generates random bytes of any length.
 It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of
 Microsoft on Windows.

 What about using a cipher here as the PRNG? It seems like using openssl
 rand_bytes() to seed aes in ctr would work ok without starving the system of
 entropy when making a lot of uuids.

There are two good reasons for us NOT to rely on OpenSSL:

1. Not all builds are done --with-openssl.

2. OpenSSL is rickety and poorly-documented, and depending on it for
more things will surely increase the pain we suffer on some great
future day when we begin supporting some other SSL library alongside
it.

-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Garick Hamlin]

On Thu, Oct 31, 2013 at 01:59:04PM -0400, Robert Haas wrote:
 On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin gham...@isc.upenn.edu wrote:
  On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
  From: Robert Haas robertmh...@gmail.com
  ISTM that the biggest problem is that we don't have a random number
  generator which generates enough bits of randomness to implement
  uuid_generate_v3.  I think relatively few people would cry if we
  didn't support uuid_generate_v1(), and the others all look simple
  enough, provided there's somewhere to get lots of random bits.
 
  On Linux, it seems like we could get those bits from /dev/urandom,
  though I'm not sure how efficient that would be for the case where
  many UUIDs are being generated at once.  But that wouldn't be very
  portable.  It's tempting to think that we'd need a PRNG that generates
  wider values, for which we might find other application also.  But I'm
  not volunteering to be the one to create such a thing.
 
  OpenSSL provides rand_bytes() which generates random bytes of any length.
  It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of
  Microsoft on Windows.
 
  What about using a cipher here as the PRNG? It seems like using openssl
  rand_bytes() to seed aes in ctr would work ok without starving the system of
  entropy when making a lot of uuids.
 
 There are two good reasons for us NOT to rely on OpenSSL:

Right, that makes sense.  openssl is a non-starter here.  In which case that
approach is no easier than any other prng.

I think using /dev/urandom directly would be surprising.  At least it would
have probably have taken me a while to figure out what was depleting the
entropy pool here.

Garick


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Christopher Browne]

On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin gham...@isc.upenn.edu wrote:
 On Thu, Oct 31, 2013 at 01:59:04PM -0400, Robert Haas wrote:
 On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin gham...@isc.upenn.edu wrote:
  On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
  From: Robert Haas robertmh...@gmail.com
  ISTM that the biggest problem is that we don't have a random number
  generator which generates enough bits of randomness to implement
  uuid_generate_v3.  I think relatively few people would cry if we
  didn't support uuid_generate_v1(), and the others all look simple
  enough, provided there's somewhere to get lots of random bits.
 
  On Linux, it seems like we could get those bits from /dev/urandom,
  though I'm not sure how efficient that would be for the case where
  many UUIDs are being generated at once.  But that wouldn't be very
  portable.  It's tempting to think that we'd need a PRNG that generates
  wider values, for which we might find other application also.  But I'm
  not volunteering to be the one to create such a thing.
 
  OpenSSL provides rand_bytes() which generates random bytes of any length.
  It uses /dev/urandom or /dev/random on UNIX/Linux and Crypto API of
  Microsoft on Windows.
 
  What about using a cipher here as the PRNG? It seems like using openssl
  rand_bytes() to seed aes in ctr would work ok without starving the system 
  of
  entropy when making a lot of uuids.

 There are two good reasons for us NOT to rely on OpenSSL:

 Right, that makes sense.  openssl is a non-starter here.  In which case that
 approach is no easier than any other prng.

 I think using /dev/urandom directly would be surprising.  At least it would
 have probably have taken me a while to figure out what was depleting the
 entropy pool here.

There's something arguably duplicative about this, but I'd be kind of
inclined to
implement an entropy pool, and enable introducing entropy using whatever
means are wished.

That way, we can scale reasonably well for all the cases.

By default, we seed using a timestamp (or similar) and use some stream cipher
that is of suitable portability to stir the pot.  That's obviously
not perfect, but it
will *work*, and offer reasonable results on systems that don't offer better
facilities.

Having a pool lends itself to stirring extra ingredients in with
reasonable ease.

- If you have a better PRNG, you can stir that in.  Perhaps it replaces the
  default; I'm not sure it's important.

 - If you have /dev/random or /dev/urandom, you can stir some of that into
   the mix.

 - Someone that is feeling paranoid about their PRNG could stir in
   data from an entropy key (like http://www.entropykey.co.uk/)

The latter options aren't much use to someone without suitable hardware or
OS support, but they're not imperative.

Doing funky things to the pool seems like an example of something useful to
do using the background worker facility of 9.3+.  And if you have an application
where you're using really a lot of UUIDs, the burden of configuring that may be
reasonable to pay.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, How would the Lone Ranger handle this?


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Robert Haas]

On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin gham...@isc.upenn.edu wrote:
 I think using /dev/urandom directly would be surprising.  At least it would
 have probably have taken me a while to figure out what was depleting the
 entropy pool here.

Perhaps so; a bigger problem IMHO is that it's not portable.  I think
the only way to solve this problem is to import (or have an option to
link with) a strong, sophisticated PRNG with much larger internal
state than pg_lrand48, which uses precisely 48 bits of internal state.
 For this kind of thing, I'm fairly sure that we need something with
at least 128 bits of internal state (as wide as the random value we
want to generate) and I suspect it might be advantageous to have
something a whole lot wider, maybe a few kB.

-- 
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

[HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[MauMau]

Hello,

For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID 
support to use UUID for primary keys.  I have to use Visual Studio 2010.


The original source code for OSSP UUID and its fork for Windows can be 
downloaded from:


http://www.ossp.org/pkg/lib/uuid/
http://sourceforge.jp/projects/sfnet_osspuuidwin32/

I built the latest version 1.6.2 and used uuid_generate_v4() as the default 
value for a primary key column of type uuid.  However, when I insert 200-300 
rows, an unique constraint violation error is reported.  It occurs 
repeatedly in several retries.


I found some people hit the same problem in the past, but they didn't seem 
to get the solution:


http://www.postgresql.org/message-id/039e01c8b63c$d0c95e90$60096cdb@IBMC9A0F63B40D
http://www.postgresql.org/message-id/018d01c8dec6$2a14b470$0b01a8c0@IBMC9A0F63B40D
http://www.postgresql.org/message-id/98B20744191F464DB598A25AB00BC125@acer08f817a9b5

When I copy lib\uuid_ossp.dll in the PostgreSQL community package, which I 
guess Dave Page san maintains, to my installation, the error does not occur. 
So, OSSP UUID library is the cause.


Saito san published a patch for OSSP UUID on his site:

http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/

And Dave san showed interest in it:

http://www.postgresql.org/message-id/snt127-w18c42125e5fd719ba514ceff...@phx.gbl

How can I build the OSSP UUID library that functions properly on Windows? Is 
OSSP UUID 1.6.2 + Saito-san's patch the exact source for the uuid-ossp.dll 
in thecommunity binary?



Regards
MauMau



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[MauMau]

Hello,

# Sorry, Saito san' address doesn't seem to exist, so excuse for sending 
again


For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID 
support to use UUID for primary keys.  I have to use Visual Studio 2010.


The original source code for OSSP UUID and its fork for Windows can be 
downloaded from:


http://www.ossp.org/pkg/lib/uuid/
http://sourceforge.jp/projects/sfnet_osspuuidwin32/

I built the latest version 1.6.2 and used uuid_generate_v4() as the default 
value for a primary key column of type uuid.  However, when I insert 200-300 
rows, an unique constraint violation error is reported.  It occurs 
repeatedly in several retries.


I found some people hit the same problem in the past, but they didn't seem 
to get the solution:


http://www.postgresql.org/message-id/039e01c8b63c$d0c95e90$60096cdb@IBMC9A0F63B40D
http://www.postgresql.org/message-id/018d01c8dec6$2a14b470$0b01a8c0@IBMC9A0F63B40D
http://www.postgresql.org/message-id/98B20744191F464DB598A25AB00BC125@acer08f817a9b5

When I copy lib\uuid_ossp.dll in the PostgreSQL community package, which I 
guess Dave Page san maintains, to my installation, the error does not occur. 
So, OSSP UUID library is the cause.


Saito san published a patch for OSSP UUID on his site:

http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/

And Dave san showed interest in it:

http://www.postgresql.org/message-id/snt127-w18c42125e5fd719ba514ceff...@phx.gbl

How can I build the OSSP UUID library that functions properly on Windows? Is 
OSSP UUID 1.6.2 + Saito-san's patch the exact source for the uuid-ossp.dll 
in thecommunity binary?



Regards
MauMau



--
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Hiroshi Saito]

Hi MauMau-san

it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/

I will be adjusted and Ralf-san again.

best regards,
Hiroshi Saito

(2013/10/30 21:45), MauMau wrote:
 Hello,
 
 # Sorry, Saito san' address doesn't seem to exist, so excuse for sending
 again
 
 For a certain reason, I need to build PostgreSQL on Windows with OSSP
 UUID support to use UUID for primary keys.  I have to use Visual Studio
 2010.
 
 The original source code for OSSP UUID and its fork for Windows can be
 downloaded from:
 
 http://www.ossp.org/pkg/lib/uuid/
 http://sourceforge.jp/projects/sfnet_osspuuidwin32/
 
 I built the latest version 1.6.2 and used uuid_generate_v4() as the
 default value for a primary key column of type uuid.  However, when I
 insert 200-300 rows, an unique constraint violation error is reported. 
 It occurs repeatedly in several retries.
 
 I found some people hit the same problem in the past, but they didn't
 seem to get the solution:
 
 http://www.postgresql.org/message-id/039e01c8b63c$d0c95e90$60096cdb@IBMC9A0F63B40D
 
 http://www.postgresql.org/message-id/018d01c8dec6$2a14b470$0b01a8c0@IBMC9A0F63B40D
 
 http://www.postgresql.org/message-id/98B20744191F464DB598A25AB00BC125@acer08f817a9b5
 
 
 When I copy lib\uuid_ossp.dll in the PostgreSQL community package, which
 I guess Dave Page san maintains, to my installation, the error does not
 occur. So, OSSP UUID library is the cause.
 
 Saito san published a patch for OSSP UUID on his site:
 
 http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/
 
 And Dave san showed interest in it:
 
 http://www.postgresql.org/message-id/snt127-w18c42125e5fd719ba514ceff...@phx.gbl
 
 
 How can I build the OSSP UUID library that functions properly on
 Windows? Is OSSP UUID 1.6.2 + Saito-san's patch the exact source for the
 uuid-ossp.dll in thecommunity binary?
 
 
 Regards
 MauMau
 
 
 



-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Alvaro Herrera]

Hiroshi Saito escribió:
 Hi MauMau-san
 
 it my bug patch applied to ver 1.6.2sorry..
 then, I made the next patch is there, please see,
 http://winpg.jp/~saito/pg_work/OSSP_win32/
 
 I will be adjusted and Ralf-san again.

At this point, I think we need to consider ossp-uuid as dead code.
Last release was in 2008 and there are lots of bugs reports still open,
even some with trivial patches attached.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Tom Lane]

Alvaro Herrera alvhe...@2ndquadrant.com writes:
 At this point, I think we need to consider ossp-uuid as dead code.

Yeah, but what shall we replace it with?  And can we preserve the
API contrib/uuid-ossp offers?  (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)

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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Andrew Dunstan]

On 10/30/2013 12:43 PM, Tom Lane wrote:

Alvaro Herrera alvhe...@2ndquadrant.com writes:

At this point, I think we need to consider ossp-uuid as dead code.

Yeah, but what shall we replace it with?  And can we preserve the
API contrib/uuid-ossp offers?  (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)





An alternative would be for someone to put up a fork on, say, github, 
and maintain it. (No, I'm not volunteering.)


cheers

andrew


--
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[MauMau]

From: Hiroshi Saito hiro...@winpg.jp

it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/

I will be adjusted and Ralf-san again.


Thanks.  Yes, I wrote the wrong URL and meant this one.  Is this patch 
(uuid-1.6.2_win32_patch2) the one that EnterpriseDB is using to publish the 
community PostgreSQL package?


Regards
MauMau



--
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[MauMau]

From: Tom Lane t...@sss.pgh.pa.us

Alvaro Herrera alvhe...@2ndquadrant.com writes:

At this point, I think we need to consider ossp-uuid as dead code.


Yeah, but what shall we replace it with?  And can we preserve the
API contrib/uuid-ossp offers?  (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)


Would it be welcomed in this community if a patch for built-in UUID 
generation functions are provided?  (I'm not saying I can provide them 
soon.)  According to the following page, Linux has libuuid.so.  Microsoft 
provides UuidCreate() as a Win32 API.  I don't know about other UNIXes.


MySQL, Oracle (and perhaps other DBMSs) offer UUID generation functions.  I 
feel it convenient if I can use that function as the default value for a 
column.


Regards
MauMau





--
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] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?

[Tom Lane]

MauMau maumau...@gmail.com writes:
 From: Tom Lane t...@sss.pgh.pa.us
 Yeah, but what shall we replace it with?  And can we preserve the
 API contrib/uuid-ossp offers?  (Maybe we shouldn't even try, but
 just deprecate that module and start fresh.)

 Would it be welcomed in this community if a patch for built-in UUID 
 generation functions are provided?

Based on what?  The reason we've held this code at arms length (in a
contrib module) is exactly that we weren't too satisfied with the
portability or adequacy of the generation methods.  Moving the functions
into core doesn't do anything to make that better; rather, it raises the
portability bar even higher, as well as making it almost impossible to
contemplate further API changes.

Note the lack of enthusiasm for taking on maintainership of the OSSP
code.  Pushing it into core would mean that we're buying into that
maintainership, hook line and sinker.  I don't think that such a
proposal would fly.

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