Re: Change atoi to strtol in same place - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Change atoi to strtol in same place
Date
Msg-id 20191017.175219.178699342607653657.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Change atoi to strtol in same place  (Joe Nelson <joe@begriffs.com>)
Responses Re: Change atoi to strtol in same place
List pgsql-hackers
At Fri, 11 Oct 2019 23:27:54 -0500, Joe Nelson <joe@begriffs.com> wrote in 
> Here's v6 of the patch.
> 
> [x] Rebase on 20961ceaf0
> [x] Don't call exit(1) after pg_fatal()
> [x] Use Tom Lane's suggestion for %lld in _() string
> [x] Allow full unsigned 16-bit range for ports (don't disallow ports 0-1023)
> [x] Explicitly cast parsed values to smaller integers

Thank you for the new version.

By the way in the upthread,

At Tue, 8 Oct 2019 01:46:51 -0500, Joe Nelson <joe@begriffs.com> wrote in 
> > I see Michael's patch is adding this new return type, but really, is
> > there a good reason why we need to do something special when the user
> > does not pass in an integer?

I agree to David in that it's better to avoid that kind of complexity
if possible. The significant point of separating them was that you
don't want to suggest a false value range for non-integer inputs.

Looking the latest patch, the wrong suggestions and the complexity
introduced by the %lld alternative are already gone. So I think we're
reaching the simple solution where pg_strtoint64_range doesn't need to
be involved in message building.

"<hoge> must be an integer in the range (mm .. xx)"

Doesn't the generic message work for all kinds of failure here?

# It is also easy for transators than the split message case.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: v12.0: segfault in reindex CONCURRENTLY
Next
From: Amit Kapila
Date:
Subject: Re: maintenance_work_mem used by Vacuum