> On 5 Mar 2020, at 06:06, Joe Nelson wrote:
>
> Daniel Gustafsson wrote:
>
>>> On 11 Feb 2020, at 17:54, Alvaro Herrera wrote:
>>>
>>> This patch doesn't currently apply; it has conflicts with at least
>>> 01368e5d9da7 and 7e735035f208; even in 7e735035f208^ it applies with
>>> fuzz. Please
Daniel Gustafsson wrote:
> > On 11 Feb 2020, at 17:54, Alvaro Herrera wrote:
> >
> > This patch doesn't currently apply; it has conflicts with at least
> > 01368e5d9da7 and 7e735035f208; even in 7e735035f208^ it applies with
> > fuzz. Please post an updated version so that it can move forward.
> On 11 Feb 2020, at 17:54, Alvaro Herrera wrote:
>
> On 2019-Dec-06, Joe Nelson wrote:
>
>> I see this patch has been moved to the next commitfest. What's the next
>> step, does it need another review?
>
> This patch doesn't currently apply; it has conflicts with at least
> 01368e5d9da7 and
On 2019-Dec-06, Joe Nelson wrote:
> I see this patch has been moved to the next commitfest. What's the next
> step, does it need another review?
This patch doesn't currently apply; it has conflicts with at least
01368e5d9da7 and 7e735035f208; even in 7e735035f208^ it applies with
fuzz. Please
On 2019-12-06 18:43, Joe Nelson wrote:
I see this patch has been moved to the next commitfest. What's the next
step, does it need another review?
I think you need to promote your patch better. The thread subject and
the commit fest entry title are somewhat nonsensical and no longer match
I see this patch has been moved to the next commitfest. What's the next
step, does it need another review?
--
Joe Nelson https://begriffs.com
At Fri, 11 Oct 2019 23:27:54 -0500, Joe Nelson 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]
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
--
Joe Nelson
David Rowley writes:
> On Tue, 8 Oct 2019 at 19:46, Joe Nelson wrote:
>> David Rowley wrote:
>>> The translation string here must be consistent over all platforms. I
>>> think this will cause issues if the translation string uses %ld and
>>> the platform requires %lld?
>> A very good and subtle
On Tue, 8 Oct 2019 at 19:46, Joe Nelson wrote:
>
> David Rowley wrote:
> > The translation string here must be consistent over all platforms. I
> > think this will cause issues if the translation string uses %ld and
> > the platform requires %lld?
>
> A very good and subtle point. I'll change it
David Rowley wrote:
> It's not for this patch to decide what ports clients can connect to
> PostgreSQL on. As far as I'm aware Windows has no restrictions on what
> ports unprivileged users can listen on. I think we're likely going to
> upset a handful of people if we block the client tools from
On Mon, Oct 7, 2019 at 11:05 AM David Rowley
wrote:
>
> On Mon, 7 Oct 2019 at 18:27, Ashutosh Sharma wrote:
> > AFAIU from the information given in the wiki page -[1], the port
> > numbers in the range of 1-1023 are for the standard protocols and
> > services. And there is nowhere mentioned that
On Mon, 7 Oct 2019 at 18:27, Ashutosh Sharma wrote:
> AFAIU from the information given in the wiki page -[1], the port
> numbers in the range of 1-1023 are for the standard protocols and
> services. And there is nowhere mentioned that it is only true for some
> OS and not for others. But, having
On Mon, Oct 7, 2019 at 10:40 AM David Rowley
wrote:
>
> On Mon, 7 Oct 2019 at 13:21, Joe Nelson wrote:
> >
> > Ashutosh Sharma wrote:
> > > One suggestion: The start value for port number is set to 1, however
> > > it seems like the port number that falls in the range of 1-1023 is
> > > reserved
On Mon, 7 Oct 2019 at 13:21, Joe Nelson wrote:
>
> Ashutosh Sharma wrote:
> > One suggestion: The start value for port number is set to 1, however
> > it seems like the port number that falls in the range of 1-1023 is
> > reserved and can't be used. So, is it possible to have the start value
> >
Ashutosh Sharma wrote:
> One suggestion: The start value for port number is set to 1, however
> it seems like the port number that falls in the range of 1-1023 is
> reserved and can't be used. So, is it possible to have the start value
> as 1024 instead of 1 ?
Good idea -- changed it. I also
Hi Joe,
On a quick look, the patch seems to be going in a good direction
although there are quite some pending work to be done.
One suggestion:
The start value for port number is set to 1, however it seems like the
port number that falls in the range of 1-1023 is reserved and can't be
used. So,
On 2019-Oct-03, Joe Nelson wrote:
> Kyotaro Horiguchi wrote:
> > > pg_standby: -k keepfiles could not parse 'hoge' as integer
> >
> > I didn't checked closely, but -k of pg_standby's message looks
> > somewhat strange. Needs a separator?
>
> Good point, how about this:
>
> pg_standby: -k
Kyotaro Horiguchi wrote:
> > pg_standby: -k keepfiles could not parse 'hoge' as integer
>
> I didn't checked closely, but -k of pg_standby's message looks
> somewhat strange. Needs a separator?
Good point, how about this:
pg_standby: -k keepfiles:
> Building a sentense just
At Tue, 01 Oct 2019 19:32:08 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20191001.193208.264851337.horikyota@gmail.com>
> Hello.
>
> At Sun, 29 Sep 2019 23:51:23 -0500, Joe Nelson wrote in
> <20190930045123.gc68...@begriffs.com>
> > Alvaro Herrera wrote:
> > > ... can we
Hello.
At Sun, 29 Sep 2019 23:51:23 -0500, Joe Nelson wrote in
<20190930045123.gc68...@begriffs.com>
> Alvaro Herrera wrote:
> > ... can we have a new patch?
>
> OK, I've attached v4. It works cleanly on 55282fa20f with
> str2int-16.patch applied. My patch won't compile without the other one
>
Alvaro Herrera wrote:
> ... can we have a new patch?
OK, I've attached v4. It works cleanly on 55282fa20f with
str2int-16.patch applied. My patch won't compile without the other one
applied too.
Changed:
[x] revert my changes in common/Makefile
[x] rename arg_utils.[ch] to option.[ch]
[x] update
On Fri, Sep 27, 2019 at 09:35:53PM -0500, Joe Nelson wrote:
> Note that it requires functions from str2int-10.patch, and will not
> compile when applied to master by itself. I didn't want to duplicate
> functionality from that other uncommitted patch in mine.
If we have a dependency between both
Alvaro Herrera wrote:
> ... can we have a new patch? Not only because there seems to have
> been some discussion points that have gone unaddressed (?)
Yes, I'll work on it over the weekend.
> but also because Appveyor complains really badly about this one.
>
... can we have a new patch? Not only because there seems to have been
some discussion points that have gone unaddressed (?), but also because
Appveyor complains really badly about this one.
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.58672
--
Álvaro Herrera
On Tue, Sep 10, 2019 at 11:54 PM Michael Paquier wrote:
> On Tue, Sep 10, 2019 at 08:03:32AM -0400, Robert Haas wrote:
> > -1. I think it's very useful to have routines for this sort of thing
> > that return an error message rather than emitting an error report
> > directly. That gives the
Robert Haas wrote:
> > -1. I think it's very useful to have routines for this sort of thing
> > that return an error message rather than emitting an error report
> > directly. That gives the caller a lot more control.
Michael Paquier wrote:
> 1) Consistency with the error messages makes less
Michael Paquier wrote:
> Using a wrapper in src/fe_utils makes sense. I would have used
> options.c for the new file, or would that be too much generic?
Sure, options.c sounds fine -- it doesn't seem any more generic than
"arg_utils" and is a little simpler. The only other question I have is
if
On Tue, Sep 10, 2019 at 08:03:32AM -0400, Robert Haas wrote:
> -1. I think it's very useful to have routines for this sort of thing
> that return an error message rather than emitting an error report
> directly. That gives the caller a lot more control.
Please let me counter-argue here. There
On Tue, Sep 10, 2019 at 1:36 AM Michael Paquier wrote:
> The error handling is awkward. I think that you should just call
> pg_log_error in pg_strtoint64_range instead of returning an error
> string as you do. You could do that by passing down the option name
> to the routine, and generate a
On Mon, Sep 09, 2019 at 11:02:49PM -0500, Joe Nelson wrote:
> Alvaro Herrera from 2ndQuadrant wrote:
> > Okay, so who is submitting a new version here? Surafel, Joe?
>
> I've attached a revision that uses pg_strtoint64 from str2int-10.patch
> (posted in ). My patch is
> based off that one and
Alvaro Herrera from 2ndQuadrant wrote:
> Okay, so who is submitting a new version here? Surafel, Joe?
I've attached a revision that uses pg_strtoint64 from str2int-10.patch
(posted in ). My patch is
based off that one and c5bc7050af.
It covers the same front-end utilities as
Alvaro Herrera from 2ndQuadrant wrote:
> Okay, so who is submitting a new version here? Surafel, Joe?
Sure, I'll look into it over the weekend.
On 2019-Jul-24, Michael Paquier wrote:
> The conclusion that we are reaching on the thread is to remove more
> dependencies on strtol that we have in the code, and replace it with
> our own, more performant wrappers. This thread makes me wondering
> that we had better wait before doing this
On 2019-07-24 16:57:42 +1200, David Rowley wrote:
> On Wed, 24 Jul 2019 at 16:02, Joe Nelson wrote:
> > > In general, I think it's a good idea to fix those places, but I wonder
> > > if we need to change the error messages too.
> >
> > I'll leave that decision for the community to debate. I did,
On Wed, Jul 24, 2019 at 04:57:42PM +1200, David Rowley wrote:
> I'd like to put my vote not to add this complex code to each option
> validation that requires an integer number. I'm not sure there
> currently is a home for it, but if there was, wouldn't it be better
> writing a function that takes
On Wed, 24 Jul 2019 at 16:02, Joe Nelson wrote:
> > In general, I think it's a good idea to fix those places, but I wonder
> > if we need to change the error messages too.
>
> I'll leave that decision for the community to debate. I did, however,
> remove the newlines for the new error messages
> Surafel Temesgen wrote:
> > we use atoi for user argument processing in same place which return
> > zero for both invalid input and input value zero. [...] in same
> > place where we accept zero as valued input it case a problem by
> > preceding for invalid input as input value zero. strtol
Hi Surafel,
On Mon, Jul 01, 2019 at 08:48:27PM +0300, Surafel Temesgen wrote:
Hello,
we use atoi for user argument processing in same place which return zero
for both invalid input and input value zero. In most case its ok because we
error out with appropriate error message for input zero but
Hello,
we use atoi for user argument processing in same place which return zero
for both invalid input and input value zero. In most case its ok because we
error out with appropriate error message for input zero but in same place
where we accept zero as valued input it case a problem by preceding
40 matches
Mail list logo
