Christoph Berg <cb@df7cb.de> writes:
> Re: Tom Lane 2014-05-25 <12508.1401045013@sss.pgh.pa.us>
>> 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
