Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD
Date
Msg-id 12508.1401045013@sss.pgh.pa.us
Whole thread Raw
In response to [PATCH] Replacement for OSSP-UUID for Linux and BSD  (Matteo Beccati <php@beccati.com>)
Responses Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD
Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD
Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD
List pgsql-hackers
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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PATCH: pgbench / int64 instead of int for xact count
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: pgbench / int64 instead of int for xact count