Re: [PATCH] Implement uuid_version()

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jose Luis Tallon <jltallon(at)adv-solutions(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Implement uuid_version()
Date: 2019-04-07 14:15:01
Message-ID: 20190407141501.GC28936@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 06, 2019 at 12:35:47PM -0400, Tom Lane wrote:
> 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.

I see some.

UUIDs turn out to be super useful in distributed systems to give good
guarantees of uniqueness without coordinating with a particular node.
Such systems have become a good bit more common since the most recent
time this was discussed.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-04-07 14:20:21 Re: Speed up transaction completion faster after many relations are accessed in a transaction
Previous Message David Rowley 2019-04-07 13:55:31 Re: Speed up transaction completion faster after many relations are accessed in a transaction