Re: [PATCH] Implement uuid_version()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jose Luis Tallon <jltallon(at)adv-solutions(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Implement uuid_version()
Date: 2019-04-06 16:35:47
Message-ID: 19808.1554568547@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> others)
> ... so please find attached a trivial patch which adds the
> functionality.

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
commit eb6f29141bed9dc95cb473614c30f470ef980705.

(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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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