Re: configure --with-uuid=bsd fails on NetBSD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: configure --with-uuid=bsd fails on NetBSD
Date
Msg-id 157385.1662742118@sss.pgh.pa.us
Whole thread Raw
In response to Re: configure --with-uuid=bsd fails on NetBSD  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: configure --with-uuid=bsd fails on NetBSD
List pgsql-hackers
Nazir Bilal Yavuz <byavuz81@gmail.com> writes:
> I updated my patch. I checked version field in 'uuid_generate_internal' 
> function instead of checking it in 'uuid_generate_v1' and 
> 'uuid_generate_v1mc' functions, but I have some questions:

Yeah, that seems like the right place.  I tweaked the code to check
strbuf not str just so we aren't making unnecessary assumptions about
the length of what is returned.  strbuf[14] is guaranteed to exist,
str[14] maybe not.

> 1 - Should it be checked only for  '--with-uuid=bsd' option?
>      1.1 - If it is needed to be checked only for '--with-uuid=bsd', 
> should just NetBSD be checked?

I don't see any reason not to check in the BSD code path --- it's
a cheap enough test.  On the other hand, in the other code paths
there is no evidence that it's necessary, and we'd find out soon
enough if it becomes necessary.

> 2 - Should it error out without including current UUID version in the 
> error message? General error message could mask if the 'uuid_create' 
> function starts to produce UUIDs other than version-4.

Yeah, I thought reporting the actual version digit was worth doing,
and made it do so.

Pushed with those changes and doc updates.  I did not push the
variant expected-file.  I think the entire point here is that
we are *not* deeming the new NetBSD implementation acceptable,
so allowing it to pass regression tests is the wrong thing.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: ICU for global collation
Next
From: Stephen Frost
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.