From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christoph Berg <cb(at)df7cb(dot)de> |
Cc: | Matteo Beccati <php(at)beccati(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD |
Date: | 2014-05-26 23:24:20 |
Message-ID: | 29295.1401146660@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christoph Berg <cb(at)df7cb(dot)de> writes:
> Re: Tom Lane 2014-05-25 <12508(dot)1401045013(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2014-05-27 00:52:32 | Re: Allowing line-continuation in pgbench custom scripts |
Previous Message | Christoph Berg | 2014-05-26 22:00:26 | Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD |