Re: phase out ossp-uuid?

Поиск
Список
Период
Сортировка
От Jose Luis Tallon
Тема Re: phase out ossp-uuid?
Дата
Msg-id 3caa6ebc-7c0b-ba49-490d-6d76f118094a@adv-solutions.net
обсуждение исходный текст
Ответ на Re: phase out ossp-uuid?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 7/2/19 23:03, Andres Freund wrote:
Hi,

On 2019-02-07 09:03:06 +0000, Dave Page wrote:
On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
I suggest we declare it deprecated in PG12 and remove it altogether in PG13.

Much as I'd like to get rid of it, we don't have an alternative for
Windows do we? The docs for 11 imply it's required for UUID support
(though the wording isn't exactly clear, saying it's required for
UUID-OSSP support!):
https://www.postgresql.org/docs/11/install-windows-full.html#id-1.6.4.8.8
Given that we've now integrated strong crypto support, and are relying
on it for security (scram), perhaps we should just add a core uuidv4?

This. But just make it "uuid" and so both parties will get their own:

On 7/2/19 11:37, I wrote:

AFAIR, Windows has its own DCE/v4 UUID generation support if needed....
UUID v5 can be generated using built-in crypto hashes. v1 are the ones (potentially) more cumbersome to generate.... plus they are the least useful IMHO.

- UUIDv3    <- with built-in crypto hashes

- UUIDv4    <- with built-in crypto random

- UUIDv5    <- with built-in crypto hashes

Only v1 remain. For those use cases one could use ossp-uuid.... so what about:

* Rename the extension's type to ossp_uuid or the like.

* Have uuid in-core (we already got the platform independent required crypto, so I wouldn't expect portability issues)

I reckon that most use cases should be either UUID v4 or UUID v5 these days. For those using v1 UUIDs, either implement v1 in core or provide some fallback/migration path; This would only affect the "uuid_generate_v1()" and "uuid_generate_v1mc()" calls AFAICS.


Moreover, the documentation (as far back as 9.4) already states:

"If you only need randomly-generated (version 4) UUIDs, consider using the gen_random_uuid() function from the pgcrypto module instead."

So just importing the datatype into core would go a long way towards removing the dependency for most users.


Thanks,

    / J.L.


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

Предыдущее
От: Amit Khandekar
Дата:
Сообщение: Re: Pluggable Storage - Andres's take
Следующее
От: "Matsumura, Ryo"
Дата:
Сообщение: RE: [PROPOSAL]a new data type 'bytea' for ECPG