Thread: phase out ossp-uuid?
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. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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.8Given 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.