On Mon, Jul 26, 2021 at 05:46:22PM +0900, Kyotaro Horiguchi wrote:
> Thanks for revising and committing! I'm fine with all of the recent
> discussions on the committed part. Though I don't think it works for
> "live" command line options, making the omitting policy symmetric
> looks good. I see the
At Mon, 26 Jul 2021 15:01:35 +0900, Michael Paquier wrote
in
> On Sat, Jul 24, 2021 at 07:41:12PM +0900, Michael Paquier wrote:
> > I have looked at that over the last couple of days, and applied it
> > after some small fixes, including an indentation.
>
> One thing that we forgot here is the h
On Sat, Jul 24, 2021 at 07:41:12PM +0900, Michael Paquier wrote:
> I have looked at that over the last couple of days, and applied it
> after some small fixes, including an indentation.
One thing that we forgot here is the handling of trailing
whitespaces. Attached is small patch to adjust that,
On Thu, Jul 22, 2021 at 02:32:35PM +0900, Michael Paquier wrote:
> Okay, done those parts as per the attached. While on it, I noticed an
> extra one for pg_dump --rows-per-insert. I am counting 25 translated
> strings cut in total.
>
> Any objections to this first step?
I have looked at that ov
On Thu, Jul 22, 2021 at 09:42:00AM -0400, Alvaro Herrera wrote:
> May I suggest for the second sentence something like "If the parsing is
> successful, returns true and stores the result in *result if that's
> given; if parsing fails, returns false"
Sounds fine to me. Thanks.
--
Michael
signatu
On 2021-Jul-21, Michael Paquier wrote:
> +/*
> + * option_parse_int
> + *
> + * Parse an integer for a given option. Returns true if the parsing
> + * could be done with optionally *result holding the parsed value, and
> + * false on failure.
> + */
May I suggest for the second sentence somethin
On Thu, Jul 22, 2021 at 01:19:41AM +1200, David Rowley wrote:
> On Thu, 22 Jul 2021 at 00:44, Michael Paquier wrote:
>>
>> On Thu, Jul 22, 2021 at 12:32:39AM +1200, David Rowley wrote:
>> > I see both of these are limited to 64 on windows. Won't those fail on
>> > Windows?
>>
>> Yes, thanks, they
On Thu, 22 Jul 2021 at 00:44, Michael Paquier wrote:
>
> On Thu, Jul 22, 2021 at 12:32:39AM +1200, David Rowley wrote:
> > I see both of these are limited to 64 on windows. Won't those fail on
> > Windows?
>
> Yes, thanks, they would. I would just cut the range numbers from the
> expected output
On Thu, Jul 22, 2021 at 12:32:39AM +1200, David Rowley wrote:
> I see both of these are limited to 64 on windows. Won't those fail on Windows?
Yes, thanks, they would. I would just cut the range numbers from the
expected output here. This does not matter in terms of coverage
either.
x> I also w
On Wed, 21 Jul 2021 at 23:50, Michael Paquier wrote:
> Hacking on that, I am finishing with the attached. It is less
> ambitious, still very useful as it removes a dozen of custom error
> messages in favor of the two ones introduced in option_utils.c. On
> top of that this reduces a bit the code
On Wed, Jul 21, 2021 at 05:02:29PM +0900, Kyotaro Horiguchi wrote:
> The difference is your suggestion is making the function output the
> message within. I guess that the reason for the original proposal is
> different style of message is required in several places.
That's one step toward having
At Thu, 15 Jul 2021 16:19:07 +0900, Michael Paquier wrote
in
> On Wed, Jul 14, 2021 at 11:02:47AM -0400, Alvaro Herrera wrote:
> > No, this doesn't work. When the first word is something that is
> > not to be translated (a literal parameter name), let's use a %s (but of
> > course the values mu
On Wed, Jul 14, 2021 at 11:02:47AM -0400, Alvaro Herrera wrote:
> On 2021-Jul-14, Kyotaro Horiguchi wrote:
>>> Should we take this occasion to reduce the burden of translators and
>>> reword that as "%s must be in range %d..%d"? That could be a separate
>>> patch.
>
> Yes, please, let's do it her
On 2021-Jul-14, Kyotaro Horiguchi wrote:
> > > pg_log_error("extra_float_digits must be in range
> > > -15..3");
> > > exit_nicely(1);
> >
> > Should we take this occasion to reduce the burden of translators and
> > reword that as "%s must be in range %d
Thanks for the discussion.
At Tue, 13 Jul 2021 09:28:30 +0900, Michael Paquier wrote
in
> On Fri, Jul 09, 2021 at 04:50:28PM +0900, Kyotaro Horiguchi wrote:
> > At Fri, 9 Jul 2021 10:29:07 +0900, Michael Paquier
> > wrote in
> >> Er, wait. We've actually allowed negative values for pg_ctl
>
On Fri, Jul 09, 2021 at 04:50:28PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 9 Jul 2021 10:29:07 +0900, Michael Paquier
> wrote in
>> Er, wait. We've actually allowed negative values for pg_ctl
>> --timeout or the subcommand kill!?
>
> --timeout accepts values less than 1, which values cause th
Thank you for the comments.
At Fri, 9 Jul 2021 10:29:07 +0900, Michael Paquier wrote
in
> On Thu, Jul 08, 2021 at 05:30:23PM +0900, Kyotaro Horiguchi wrote:
> > [1] is trying to expose pg_strtoint16/32 to frontend, but I don't see
> > much point in doing that in conjunction with [2] or this thr
On Thu, Jul 08, 2021 at 05:30:23PM +0900, Kyotaro Horiguchi wrote:
> Looked through the three threads.
Thanks!
> [1] is trying to expose pg_strtoint16/32 to frontend, but I don't see
> much point in doing that in conjunction with [2] or this thread. Since
> the integral parameter values of pg-com
At Wed, 7 Jul 2021 17:40:13 +0530, Bharath Rupireddy
wrote in
> On Fri, Jun 4, 2021 at 10:23 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Jun-04, Bharath Rupireddy wrote:
> >
> > > On Fri, Jun 4, 2021 at 8:58 PM Alvaro Herrera
> > > wrote:
> >
> > > > I would suggest that the best way forward
On Fri, Jun 4, 2021 at 10:23 PM Alvaro Herrera wrote:
>
> On 2021-Jun-04, Bharath Rupireddy wrote:
>
> > On Fri, Jun 4, 2021 at 8:58 PM Alvaro Herrera
> > wrote:
>
> > > I would suggest that the best way forward in this area is to rebase both
> > > there patches on current master.
> >
> > Thanks
On 2021-Jun-04, Bharath Rupireddy wrote:
> On Fri, Jun 4, 2021 at 8:58 PM Alvaro Herrera wrote:
> > I would suggest that the best way forward in this area is to rebase both
> > there patches on current master.
>
> Thanks. I will read both the threads [1], [2] and try to rebase the
> patches. If
On Fri, Jun 4, 2021 at 8:58 PM Alvaro Herrera wrote:
>
> On 2021-Jun-04, Bharath Rupireddy wrote:
>
> > On Thu, May 27, 2021 at 3:05 AM Alvaro Herrera
> > wrote:
> > > Hi, how is this related to
> > > https://postgr.es/m/20191028012000.ga59...@begriffs.com ?
> >
> > Thanks. The proposed approach
On 2021-Jun-04, Bharath Rupireddy wrote:
> On Thu, May 27, 2021 at 3:05 AM Alvaro Herrera
> wrote:
> > Hi, how is this related to
> > https://postgr.es/m/20191028012000.ga59...@begriffs.com ?
>
> Thanks. The proposed approach there was to implement postgres's own
> strtol i.e. string parsing, c
On Thu, May 27, 2021 at 3:05 AM Alvaro Herrera wrote:
>
> On 2021-May-19, Bharath Rupireddy wrote:
>
> > While working on [1], I found that some parts of the code is using
> > strtol and atoi without checking for non-numeric junk input strings. I
> > found this strange. Most of the time users prov
On 2021-May-19, Bharath Rupireddy wrote:
> While working on [1], I found that some parts of the code is using
> strtol and atoi without checking for non-numeric junk input strings. I
> found this strange. Most of the time users provide proper numeric
> strings but there can be some scenarios where
Hi,
While working on [1], I found that some parts of the code is using
strtol and atoi without checking for non-numeric junk input strings. I
found this strange. Most of the time users provide proper numeric
strings but there can be some scenarios where these strings are not
user-supplied but gene
26 matches
Mail list logo
