Re: refactoring - share str2*int64 functions
| От | Fabien COELHO |
|---|---|
| Тема | Re: refactoring - share str2*int64 functions |
| Дата | |
| Msg-id | alpine.DEB.2.21.1904201322560.29102@lancre обсуждение исходный текст |
| Ответ на | refactoring - share str2*int64 functions (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: refactoring - share str2*int64 functions
|
| Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: