Re: refactoring - share str2*int64 functions

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: refactoring - share str2*int64 functions
Date: 2019-07-15 01:43:50
Message-ID: CA+hUKGKVkGQQx6NeXfJCmEsa4fvbu3WLRcSOkdzkNTZRSc-RCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 14, 2019 at 3:22 AM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> Here is the updated patch on which I checked "make check-world".

Thanks! So, we're moving pg_strtouint64() to a place where frontend
code can use it, and getting rid of some duplication. I like it. I
wanted this once before myself[1].

+extern bool pg_strtoint64(const char *str, bool errorOK, int64 *result);
+extern uint64 pg_strtouint64(const char *str, char **endptr, int base);

One of these things is not like the other. Let's see... the int64
version is used only by pgbench and is being promoted to common where
it can be used by more code. With a name like that, wouldn't it make
sense to bring it into line with the uint64 interface, and then move
pgbench's error reporting stuff back into pgbench? The uint64 one
derives its shape from the family of standard functions like strtol()
so I think it wins.

[1] https://www.postgresql.org/message-id/CAEepm=2KeC8xDbEWgDTDObXGqPHFW4kcD7BZXR6NMfiHjjnKhQ@mail.gmail.com

--
Thomas Munro
https://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-07-15 01:46:08 Re: Using unique btree indexes for pathkeys with one extra column
Previous Message Tomas Vondra 2019-07-15 01:34:25 Re: [sqlsmith] Crash in mcv_get_match_bitmap