Re: phase out ossp-uuid?

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(dot)eisentraut(at)2ndquadrant(dot)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
<https://www.postgresql.org/docs/9.4/pgcrypto.html> module instead."

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

Thanks,

    / J.L.