|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Jose Luis Tallon <jltallon(at)adv-solutions(dot)net>|
|Subject:||Re: [PATCH] Implement uuid_version()|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Jose Luis Tallon <jltallon(at)adv-solutions(dot)net> writes:
> While working on an application, the need arose to be able
> efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
> ... so please find attached a trivial patch which adds the
No particular objection...
> I'm not sure whether this actually would justify a version bump for
> the OSSP-UUID extension
Yes. Basically, once we've shipped a given version of an extension's
SQL script, that version is *frozen*. Anything at all that you want
to do to it has to be done in an extension update script, because
otherwise there's no clean migration path for users.
So basically, leave uuid-ossp--1.1.sql as it stands, and put the
new CREATE FUNCTION in a new uuid-ossp--1.1--1.2.sql script.
See any recent patch that updated an extension for an example, eg
(We do allow exceptions when somebody's already updated the extension
in the current devel cycle, but that doesn't apply here.)
> Another matter, which I'd like to propose in a later thread, is
> whether it'd be interesting to include the main UUID functionality
> directly in core
We've rejected that before, and I don't see any reason to think
the situation has changed since prior discussions.
regards, tom lane
|Next Message||Tom Lane||2019-04-06 18:07:55||tableam scan-API patch broke foreign key validation|
|Previous Message||Fabien COELHO||2019-04-06 16:31:11||pgbench - extend initialization phase control|