Re: Tom Lane 2014-05-25 <12508.1401045013@sss.pgh.pa.us>
> Matteo Beccati <php@beccati.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.
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.
This would make pg_dump upgrades work. No idea about pg_upgrade, but I
wanted to post that idea here, as it didn't seem to have been
discussed yet.
> 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.
Christoph
--
cb@df7cb.de | http://www.df7cb.de/