On 8/4/19 17:06, Robert Haas wrote:
> On Sun, Apr 7, 2019 at 10:15 AM David Fetter <david@fetter.org> wrote:
>> I see some.
>>
>> UUIDs turn out to be super useful in distributed systems to give good
>> guarantees of uniqueness without coordinating with a particular node.
>> Such systems have become a good bit more common since the most recent
>> time this was discussed.
> That's not really a compelling reason, though, because anybody who
> needs UUIDs can always install the extension. And on the other hand,
> if we moved UUID support into core, then we'd be adding a hard compile
> dependency on one of the UUID facilities, which might annoy some
> developers. We could possibly work around that by implementing our
> own UUID facilities in core,
Yup. My proposal basically revolves around implementing v3 / v4 / v5
(most used/useful versions for the aforementioned use cases) in core,
using the already existing md5 and sha1 facilities (which are already
being linked from the current uuid-ossp extension as fallback with
certain configurations) ... and leaving the remaining functionality in
the extension, just as it is now.
This way, we guarantee backwards compatibility: Those already using the
extension wouldn't have to change anything, and new users won't need to
load any extension to benefit from this (base) functionality.
> but I'm not volunteering to do the work,
Of course, I'd take care of that :)
> and I'm not sure that the work has enough benefit to justify the
> labor.
With this "encouragement", I'll write the code and submit the patches to
a future commitfest. Then the normal procedure will take care of judging
whether it's worth being included or not :$
> My biggest gripe about uuid-ossp is that the name is stupid. I wish
> we could see our way clear to renaming that extension to just 'uuid',
> because as J.L. says, virtually nobody's actually compiling against
> the OSSP library any more. The trick there is how to do that without
> annoying exiting users. Maybe we could leave behind an "upgrade"
> script for the uuid-ossp extension that does CREATE EXTENSION uuid,
> then alters all objects owned by the current extension to be owned by
> the new extension, and maybe even drops itself.
I believe my proposal above mostly solves the issue: new users with
"standard" needs won't need to load any extension (better than current),
old users will get the same functionality as they have today (only part
in core and part in the extension)...
...and a relatively simple "alias" (think Linux kernel modules)
facility would make the transition fully transparent: rename extension
to "uuid" ---possibly dropping the dependency on uuid-ossp in the
process--- and expose an "uuid-ossp" alias for backwards compatibility.
Thanks,
J.L.