Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD

Hi Tom,

thanks for the feedback.

On 25/05/2014 21:10, Tom Lane wrote:
> Matteo Beccati <php(at)beccati(dot)com> writes:
>> here's the latest version of my uuid changes patch, according to
>> proposal (2) from Tom in the thread about OSSP-UUID[1].
>
> 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.

Sure, that makes sense. I wasn't actually sure it was ok to keep the
"OSSP" brand even though the extensions didn't use the oosp library,
hence the renaming. But I do agree upgrades wouldn't be very easy if we
don't.

> In the long run it'd be nice to migrate away from the "uuid-ossp"
> extension name, mostly because of the poorly-chosen use of a dash in the
> name. But I'm not sure how we do that without breaking backwards
> compatibility, and anyway it's an entirely cosmetic thing that we can
> worry about later.
>
> Anyhow, doing it like that seems like it ought to be a pretty
> straightforward refactoring of your patch. I could pursue that,
> or you can.

I do have a system with the ossp library installed: I'd be happy to give
it a try tomorrow morning my time, depending on my workload. I'll keep
you posted!

Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/