From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | refactoring - share str2*int64 functions |
Date: | 2019-04-20 11:22:02 |
Message-ID: | alpine.DEB.2.21.1904201223040.29102@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
>> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2019-04-20 11:23:42 | Re: refactoring - share str2*int64 functions |
Previous Message | Stephen Frost | 2019-04-20 04:42:38 | Re: finding changed blocks using WAL scanning |