| 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: | Re: refactoring - share str2*int64 functions |
| Date: | 2019-04-20 11:23:42 |
| Message-ID: | alpine.DEB.2.21.1904201322560.29102@lancre |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| share-strtoX64-functions-1.patch | text/x-diff | 18.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2019-04-20 11:53:26 | Re: pgsql: Allow insert and update tuple routing and COPY for foreign table |
| Previous Message | Fabien COELHO | 2019-04-20 11:22:02 | refactoring - share str2*int64 functions |