Re: refactoring - share str2*int64 functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id alpine.DEB.2.21.1904201322560.29102@lancre
Whole thread Raw
In response to refactoring - share str2*int64 functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: refactoring - share str2*int64 functions
List pgsql-hackers
As usual, it is better with the attachement. Sorry for the noise.

>>> Yep, but ISTM that it is down to 32 bits,
>> 
>> Only on 32-bit-long machines, which are a dwindling minority (except
>> for Windows, which I don't really care about).
>> 
>>> So the third short is now always 0. Hmmm. I'll propose another option over
>>> the week-end.
>> 
>> I suppose we could put pg_strtouint64 somewhere where pgbench can use it,
>> but TBH I don't think it's worth the trouble.  The set of people using
>> the --random-seed=int option at all is darn near empty, I suspect,
>> and the documentation only says you can write an int there.
>
> Although I agree it is not worth a lot of trouble, and even if I don't do 
> Windows, I think it valuable that the behavior is the same on all platform. 
> The attached match shares pg_str2*int64 functions between frontend and 
> backend by moving them to "common/", which avoids some code duplication.
>
> This is more refactoring, and it fixes the behavior change on 32 bit 
> architectures.
>
>

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: refactoring - share str2*int64 functions
Next
From: Bruce Momjian
Date:
Subject: Re: finding changed blocks using WAL scanning