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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD
Date: 2014-05-25 19:10:13
Message-ID: 12508.1401045013@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-05-25 19:21:46 Re: PATCH: pgbench / int64 instead of int for xact count
Previous Message Tom Lane 2014-05-25 18:32:51 Re: PATCH: pgbench / int64 instead of int for xact count