Christoph Berg <> writes:
> Re: Tom Lane 2014-05-25 <>
>> Hmm ... this is not actually what I had in mind.  Unless I'm misreading
>> the patch, this nukes the "uuid-ossp" extension entirely in favor of a
>> new extension "uuid" (providing the same SQL functions with a different
>> underlying implementation).  I don't think this works from the standpoint
>> of providing compatibility for users of the existing extension.
>> In particular, it'd break pg_upgrade (because of the change of the .so
>> library name) as well as straight pg_dump upgrades (which would expect
>> CREATE EXTENSION "uuid-ossp" to work).  Not to mention application code
>> that might expect CREATE EXTENSION "uuid-ossp" to still work.
>> Another objection is that for people for whom OSSP uuid still works fine,
>> this is forcing them to adopt a new implementation whose compatibility is
>> as yet unproven.
>> What I'd rather do is preserve contrib/uuid-ossp with the same extension
>> and .so name, but with two configure options that select different
>> underlying implementations.

> What I'd propose is to have a "pure" uuid extension using native OS
> functions, so people starting a new database could go for that without
> any OSSP legacy. The ossp-uuid extension would then have a dependency
> (like earthdistance has requires = 'cube'), plus maybe compatibility
> functions to call the proper functions from uuid.

The only thing that seems particularly "legacy" about this design is that
the extension is still named uuid-ossp.  While that's certainly annoying
when the implementation isn't using OSSP, I'm not really seeing the value
of providing two near-duplicate extensions.  And no, what you suggest
doesn't work well with pg_upgrade.  I'm not even sure it works well
ignoring that issue: the new extension would have to choose all-new
function names so that it could be installed alongside uuid-ossp.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to