Re: [PATCH] Implement uuid_version()

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: [PATCH] Implement uuid_version()
Дата
Msg-id 20190407141501.GC28936@fetter.org
обсуждение исходный текст
Ответ на Re: [PATCH] Implement uuid_version()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Implement uuid_version()  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sat, Apr 06, 2019 at 12:35:47PM -0400, Tom Lane wrote:
> Jose Luis Tallon <jltallon@adv-solutions.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Speed up transaction completion faster after many relations areaccessed in a transaction
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Speed up transaction completion faster after many relations are accessed in a transaction