On Mon, Dec 18, 2023 at 09:31:54PM -0500, Tom Lane wrote:
> Agreed, if it actually is 19 years old. I'm wondering a little bit
> if there could be some moderately-recent glibc behavior change
> involved. I'm not excited enough about it to go trawl their change
> log, but we should keep our ears c
Nathan Bossart writes:
> On Mon, Dec 18, 2023 at 02:41:22PM -0500, Tom Lane wrote:
>> We just had a user complaint that seems to trace to exactly this
>> bogus reporting in pg_ctl [1]. Although I was originally not
>> very pleased with changing our getopt_long to do switch reordering,
>> I'm now
On Mon, Dec 18, 2023 at 02:41:22PM -0500, Tom Lane wrote:
> We just had a user complaint that seems to trace to exactly this
> bogus reporting in pg_ctl [1]. Although I was originally not
> very pleased with changing our getopt_long to do switch reordering,
> I'm now wondering if we should back-pa
Michael Paquier writes:
> On Thu, Jul 13, 2023 at 09:38:42PM -0700, Nathan Bossart wrote:
>> Take the following examples of client programs that accept one non-option:
>>
>> ~$ pg_resetwal a b c
>> pg_resetwal: error: too many command-line arguments (first is "b")
>> pg_resetwal: hint: Try "pg_re
On Fri, Jul 14, 2023 at 02:02:28PM +0900, Michael Paquier wrote:
> Objection withdrawn.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jul 13, 2023 at 09:38:42PM -0700, Nathan Bossart wrote:
> I did notice this, but I had the opposite reaction.
Ahah, well ;)
> Take the following examples of client programs that accept one non-option:
>
> ~$ pg_resetwal a b c
> pg_resetwal: error: too many command-line argume
On Fri, Jul 14, 2023 at 01:27:26PM +0900, Michael Paquier wrote:
> Indeed, it looks like I've fat-fingered a rebase here. I am able to
> get a clean CI run when running this patch, sorry for the noise.
>
> Anyway, this introduces a surprising behavior when specifying too many
> subcommands. On H
On Thu, Jul 13, 2023 at 07:57:12AM -0700, Nathan Bossart wrote:
> Assuming you are referring to [0], it looks like you are missing 411b720.
>
> [0] https://github.com/michaelpq/postgres/commits/getopt_test
Indeed, it looks like I've fat-fingered a rebase here. I am able to
get a clean CI run whe
On Thu, Jul 13, 2023 at 02:39:32PM +0900, Michael Paquier wrote:
> Something does not seem to be right seen from here, a CI run with
> Windows 2019 fails when using pg_ctl at the beginning of most of the
> tests, like:
> [04:56:07.404] - 8<
> ---
At Thu, 13 Jul 2023 14:39:32 +0900, Michael Paquier wrote
in
> [04:56:07.404] pg_ctl: too many command-line arguments (first is "-D")
Mmm. It checks, for example, for "pg_ctl initdb -D $tempdir/data -o
-N". This version of getopt_long() returns -1 as soon as it meets the
first non-option "init
On Wed, Jul 12, 2023 at 08:49:03PM -0700, Nathan Bossart wrote:
> After a couple more small edits, I've committed this. I looked through all
> uses of getopt_long() in PostgreSQL earlier today, and of the programs that
> accepted non-options, most accepted only one, some others accepted 2-3, and
>
On Tue, Jul 11, 2023 at 09:32:32AM -0700, Nathan Bossart wrote:
> Sure. І did it this way in v7.
After a couple more small edits, I've committed this. I looked through all
uses of getopt_long() in PostgreSQL earlier today, and of the programs that
accepted non-options, most accepted only one, so
On Tue, Jul 11, 2023 at 04:16:09PM +0900, Kyotaro Horiguchi wrote:
> I like it. We don't need to overcomplicate things just for the sake of
> speed here. Plus, this version looks the most simple to me. That being
> said, it might be better if the last term is positioned in the second
> place. This
At Mon, 10 Jul 2023 13:06:58 -0700, Nathan Bossart
wrote in
> Here's a new version of the patch with the latest feedback addressed.
Thanks!
+* An argument is a non-option if it meets any of the following
+* criteria: it follows an argument that is equivalent to
Here's a new version of the patch with the latest feedback addressed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From e662a1b6b73c92ff7862444e092406ed82b0c2c7 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 7 Jul 2023 20:00:47 -0700
Subject: [PATCH v6 1/1] Teach in-t
On Mon, Jul 10, 2023 at 04:57:11PM +0900, Kyotaro Horiguchi wrote:
> + if (!force_nonopt && place[0] == '-' && place[1])
> + {
> + if (place[1] != '-' || place[2])
> + break;
> +
> +
At Fri, 7 Jul 2023 20:52:24 -0700, Nathan Bossart
wrote in
> I spent some time tidying up the patch and adding a more detailed commit
> message.
The commit message and the change to TAP script looks good.
Two conditions are to be reversed and one of them look somewhat
unintuitive to me.
+
I spent some time tidying up the patch and adding a more detailed commit
message.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 2525e6aed066fe8eafdaab0d33c8c5df055c7e09 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 7 Jul 2023 20:00:47 -0700
Subject: [PATCH v5 1/1
On Tue, Jun 20, 2023 at 02:12:44PM +0900, Kyotaro Horiguchi wrote:
> The argv elements get shuffled around many times with the
> patch. However, I couldn't find a way to decrease the count without
> resorting to a forward scan. So I've concluded the current approach
> is them most effeicient, cons
At Fri, 16 Jun 2023 11:28:47 -0700, Nathan Bossart
wrote in
> On Fri, Jun 16, 2023 at 04:51:38PM +0900, Kyotaro Horiguchi wrote:
> > (Honestly, the rearrangement code looks somewhat tricky to grasp..)
>
> Yeah, I think there's still some room for improvement here.
The argv elements get shuffle
On Fri, Jun 16, 2023 at 04:51:38PM +0900, Kyotaro Horiguchi wrote:
> (Honestly, the rearrangement code looks somewhat tricky to grasp..)
Yeah, I think there's still some room for improvement here.
> It doesn't work properly if '--' is involved.
>
> For example, consider the following options (ev
At Thu, 15 Jun 2023 21:58:28 -0700, Nathan Bossart
wrote in
> On Fri, Jun 16, 2023 at 10:30:09AM +0900, Michael Paquier wrote:
> > On Thu, Jun 15, 2023 at 05:09:59PM -0700, Nathan Bossart wrote:
> >> I've attached a new version of the patch that omits the
> >> POSIXLY_CORRECT stuff.
> >
> > Thi
On Fri, Jun 16, 2023 at 10:30:09AM +0900, Michael Paquier wrote:
> On Thu, Jun 15, 2023 at 05:09:59PM -0700, Nathan Bossart wrote:
>> I've attached a new version of the patch that omits the
>> POSIXLY_CORRECT stuff.
>
> This looks OK at quick glance, though you may want to document at the
> top of
On Thu, Jun 15, 2023 at 05:09:59PM -0700, Nathan Bossart wrote:
> On Thu, Jun 15, 2023 at 02:30:34PM +0900, Kyotaro Horiguchi wrote:
>> Hmm, the discussion seems to be based on the assumption that argv[0]
>> can be safely redirected to a different memory location. If that's the
>> case, we can prpb
On Thu, Jun 15, 2023 at 02:30:34PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 14 Jun 2023 15:46:08 -0700, Nathan Bossart
> wrote in
>> Hm. IIUC modifying the argv pointers on AIX will modify the process title,
>> which could cause 'ps' to temporarily show duplicate/missing arguments
>> during op
At Wed, 14 Jun 2023 15:46:08 -0700, Nathan Bossart
wrote in
> On Wed, Jun 14, 2023 at 03:11:54PM -0700, Noah Misch wrote:
> > Here's some output from this program (on AIX 7.1, same output when compiled
> > 32-bit or 64-bit):
> >
> > $ ./a.out a b c d e f
> > f e d c b a ./a.out
>
> Thanks agai
On Wed, Jun 14, 2023 at 03:11:54PM -0700, Noah Misch wrote:
> Here's some output from this program (on AIX 7.1, same output when compiled
> 32-bit or 64-bit):
>
> $ ./a.out a b c d e f
> f e d c b a ./a.out
Thanks again.
> Interesting discussion here, too:
> https://github.com/libuv/libuv/pull/1
On Wed, Jun 14, 2023 at 02:28:16PM -0700, Nathan Bossart wrote:
> On Tue, Jun 13, 2023 at 05:17:37PM -0700, Noah Misch wrote:
> > If you have a test program to be run, I can run it on AIX.
>
> Thanks. The patch above [0] adjusts 040_createuser.pl to test modifying
> argv, so that's one test progr
On Tue, Jun 13, 2023 at 05:17:37PM -0700, Noah Misch wrote:
> If you have a test program to be run, I can run it on AIX.
Thanks. The patch above [0] adjusts 040_createuser.pl to test modifying
argv, so that's one test program. And here's a few lines for reversing
argv:
#include
On Wed, Jun 14, 2023 at 09:03:22AM +0900, Michael Paquier wrote:
> On Wed, Jun 14, 2023 at 08:52:27AM +0900, Michael Paquier wrote:
> > On Tue, Jun 13, 2023 at 03:36:57PM -0700, Nathan Bossart wrote:
> >> Windows seems to allow rearranging argv, based upon cfbot's results. I do
> >> not know about
On Wed, Jun 14, 2023 at 08:52:27AM +0900, Michael Paquier wrote:
> On Tue, Jun 13, 2023 at 03:36:57PM -0700, Nathan Bossart wrote:
>> Windows seems to allow rearranging argv, based upon cfbot's results. I do
>> not know about AIX. In any case, C99 explicitly mentions that argv should
>> be modifi
On Tue, Jun 13, 2023 at 03:36:57PM -0700, Nathan Bossart wrote:
> Windows seems to allow rearranging argv, based upon cfbot's results. I do
> not know about AIX. In any case, C99 explicitly mentions that argv should
> be modifiable.
Few people have AIX machines around these days, but looking aro
On Tue, Jun 13, 2023 at 04:02:01PM +0900, Kyotaro Horiguchi wrote:
> Hmm. from the initial mail, I got the impression that AIX and Windows
> allow this, so I thought that we can do that for them. While there
> could be other platforms that allow it, perhaps we don't need to go as
> far as extendin
At Mon, 12 Jun 2023 22:13:43 -0700, Nathan Bossart
wrote in
> On Tue, Jun 13, 2023 at 12:00:01PM +0900, Kyotaro Horiguchi wrote:
> > POSIXLY_CORRECT appears to be intended for debugging or feature
> > validation. If we know we can always rearrange argv on those
> > platforms, we don't need it.
On Tue, Jun 13, 2023 at 12:00:01PM +0900, Kyotaro Horiguchi wrote:
> POSIXLY_CORRECT appears to be intended for debugging or feature
> validation. If we know we can always rearrange argv on those
> platforms, we don't need it. I would suggest that we turn on the new
> feature at the compile time o
At Fri, 9 Jun 2023 16:22:57 -0700, Nathan Bossart
wrote in
> While working on 2dcd157, I noticed cfbot failures for Windows due to tests
> with commands that had non-options specified before options. For example,
> "createuser myrole -a myadmin" specified a non-option (myrole) before the
> opti
While working on 2dcd157, I noticed cfbot failures for Windows due to tests
with commands that had non-options specified before options. For example,
"createuser myrole -a myadmin" specified a non-option (myrole) before the
option/argument pair (-a admin). To get the tests passing for Windows,
no
37 matches
Mail list logo