phase out ossp-uuid?

On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:

I'm wondering whether we should phase out the use of the ossp-uuid
library? (not the uuid-ossp extension) We have had preferred
alternatives for a while now, so it shouldn't be necessary to use this
anymore, except perhaps in some marginal circumstances? As we know,
ossp-uuid isn't maintained anymore, and a few weeks ago the website was
gone altogether, but it seems to be back now.

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

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 7/2/19 10:03, Dave Page wrote:

On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:

I'm wondering whether we should phase out the use of the ossp-uuid
library? (not the uuid-ossp extension)

Hmm... FWIW, just get it in core altogether? Seems small and useful
enough... if it carries the opfamily with it, UUID would become really
convenient to use for distributed applications.

(being using that functionality for a while, already)

We have had preferred
alternatives for a while now, so it shouldn't be necessary to use this
anymore, except perhaps in some marginal circumstances? As we know,
ossp-uuid isn't maintained anymore, and a few weeks ago the website was
gone altogether, but it seems to be back now.

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

AFAIR, Windows has its own DCE/v4 UUID generation support. 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.

Just my .02€

Thanks,

    / J.L.

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

I'm wondering whether we should phase out the use of the ossp-uuid
library?

It's not really costing us any maintenance effort that I've noticed,
so I vote no. Whether or not there are any people who can't use
another alternative, it would be more work to rip out that code than
to (continue to) ignore it.

regards, tom lane

On 07/02/2019 10:03, Dave Page wrote:

Much as I'd like to get rid of it, we don't have an alternative for
Windows do we?

Yes, that appears to be a significant problem, so we'll have to keep it
for the time being.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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'm wondering whether we should phase out the use of the ossp-uuid
library? (not the uuid-ossp extension) We have had preferred
alternatives for a while now, so it shouldn't be necessary to use this
anymore, except perhaps in some marginal circumstances? As we know,
ossp-uuid isn't maintained anymore, and a few weeks ago the website was
gone altogether, but it seems to be back now.

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?

Greetings,

Andres Freund

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
<https://www.postgresql.org/docs/9.4/pgcrypto.html&gt; module instead."

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

Thanks,

    / J.L.