mark@mark.mielke.cc wrote:
>> Really this whole debate only reinforces the point that there isn't
>> a single way of doing UUID generation. There are multiple libraries
>> out there each with pros and cons. It makes more sense to have
>> multiple pgfoundry UUID generating modules.
>
> Exactly. If I lead you to the impression that I want UUIDv1 in core, this
> was not the intent. What I intend to say is that different people want
> different implementations, and one of the most useful versions, in my
> opinion, is difficult to implement portably.
Actually, you could do it very portably, at the cost of a minute or so's
worth of configuration. Simply have a GUC variable called, say,
uuid_mac_address. Then the person who gets a box of dud NICs or who,
like me, has a virtual server somewhere without a true ethernet port
visible to the operating system, can easily set it. No cross-platform
code, no requirement to build a third party module in contrib (at least
not for v1 uuids).
I actually DO think that we should have at least one default generation
routine in core, even if the above idea doesn't float and it's just v4
random numbers. If we advertise that we have uuids, people will not
expect to have to install a contrib module just to get some values
generated. The SQL server function newsequentialid() which gives v1
uuids, sort of, is ONLY available as a default value for a column, you
can't use it in normal expressions (figure that out). So people clearly
will expect to be able to generate these at the database level.
Using either v1s as configured above or v4s, there's no portability
issue. Indeed MS SQL Server has a both available (newsequentialid() and
newid()). And sufficient documentation should allow people to make their
minds up regarding what their needs are. If they really want funky v3
namespace ones then they can install a contrib, no problem with that.
Cheers
Tom
