Re: refactoring - share str2*int64 functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id alpine.DEB.2.21.1908011118370.2692@lancre
Whole thread Raw
In response to Re: refactoring - share str2*int64 functions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: refactoring - share str2*int64 functions  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michaël-san,

>> I have looked quickly at it, but I'm not sure that there is an agreement
>> about what should be done precisely, so the feedback is not clearly
>> actionable.
>
> Per the latest trends, it seems that the input of Andres was kind of
> the most interesting pieces.

Yes, definitely. I understood that we want in "string.h" something like
(just the spirit):

   typedef enum {
     STRTOINT_OK, STRTOINT_RANGE_ERROR, STRTOINT_SYNTAX_ERROR
   } strtoint_status;

   strtoint_status pg_strtoint64(const char * str, int64 * result);

However there is a contrary objective to have a unified interface,
but there also exists a:

   extern uint64 pg_strtouint64(const char *str, char **endptr, int base);

called 3 times, always with base == 10. We have a similar name but a 
totally different interface, so basically it would have to be replaced
by something like the first interface.

> If you don't have room for it, I would not mind doing the legwork 
> myself.

I think that it would be quick if the what is clear enough, so I can do 
it.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Store FullTransactionId in TwoPhaseFileHeader/GlobalTransactionData
Next
From: Etsuro Fujita
Date:
Subject: Re: partition routing layering in nodeModifyTable.c