Re: refactoring - share str2*int64 functions
От | Michael Paquier |
---|---|
Тема | Re: refactoring - share str2*int64 functions |
Дата | |
Msg-id | 20190717030432.GD2130@paquier.xyz обсуждение исходный текст |
Ответ на | Re: refactoring - share str2*int64 functions (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: refactoring - share str2*int64 functions
|
Список | pgsql-hackers |
On Tue, Jul 16, 2019 at 01:18:38PM -0700, Andres Freund wrote: > Hi, > > On 2019-07-16 16:11:44 +0900, Michael Paquier wrote: > Yea, consistent naming seems like a strong requirement > here. Additionally I think we should just provide a consistent set > rather than what's needed just now. That'll just lead to people > inventing their own again down the line. Agreed. The first versions of pg_rewind in the tree have been using copy_file_range(), which has been introduced in Linux. > > - The str->integer conversion routines, which actually have very > > similar characteristics to the strtol families as they remove trailing > > whitespaces first, check for a sign, etc, except that they work only > > on base 10. > > There's afaict neither a caller that needs the base argument at the > moment, nor one in the tree previously. I'd argue for just making > pg_strtouint64's API consistent. Good point, indeed, this could be much more simplified. I have not paid attention at that part. > I'd probably also just use the implementation we have for signed > integers (minus the relevant negation and overflow checks, obviously) - > it's a lot faster, and I think there's value in keeping the > implementations in sync. You mean that it is much faster than the set of wrappers for strtol than we have? Is that because we don't care about the base? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: