Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ni5zp-0001ls-7G for pgsql-hackers@arkaria.postgresql.org; Sat, 23 Apr 2022 02:59:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ni5zl-0000PA-S8 for pgsql-hackers@arkaria.postgresql.org; Sat, 23 Apr 2022 02:59:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ni5zl-0000Op-B4 for pgsql-hackers@lists.postgresql.org; Sat, 23 Apr 2022 02:59:37 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ni5zg-0006RF-A7 for pgsql-hackers@lists.postgresql.org; Sat, 23 Apr 2022 02:59:35 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-e604f712ecso10535920fac.9 for ; Fri, 22 Apr 2022 19:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=01IPYourZWpqVQs6S8XwKR0smXiuUromAovXt2hb6fs=; b=TZJGhaGE4lIK3o970zDnzywb/qnYfFSrQ0gAoz9Lk1dn5QYgqAZYaMHJJJOVc4wPKh mvXJTRAaA3Nbi1phElCK2haKkeXtbXI30EHSV5yjx1nUmc+ODxbVXEbDiNdaGaZK6me4 0mV2h4XOWqMz/1v9hK4sadg+nWYrYjh2wkwiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=01IPYourZWpqVQs6S8XwKR0smXiuUromAovXt2hb6fs=; b=sgtT8oVyIYPtIdfXskUNejPSLRI5IzodWrCtdWPROGwUJgouyzq10q5gkBK/XvuDee Y+PbVYxT8khF2EouzLo32FlxiQwcbQuPOQESO3dC3yZAP0a1dz33Y+WeyX8JGpu53xxT szOyZyu8D5QXSKqyt1IFBRL/lRcU+UVu+UmknEDocRHDrIwaE33h95E/1LPyXbs5hXoS zbKS9iPWfb1W0Um8IjO+z3dNTkxbQKtiHQbLTB5Eyj4ycj4TrDa/cgb4DwvA96XN56ol SnjWD5vyZ5bhSZRVpu67m2sNmlknZpUorT54Srbh07aGbSHh2eZMVJeiqgRdN5AFnQzd CFrA== X-Gm-Message-State: AOAM5331l66o3IEIvzj3isy1F+ajhsMSXkHL+q56eI6m5OFFi5JR1Ex7 SB5JJsWJqIefxaPIgsO32v7nkg== X-Google-Smtp-Source: ABdhPJyYbDuSB67kVuwH2tDRqR3+cWtLg8nVdmmsCuqKaML5zpNOZSImGR/vl6Vh3TFCNDJynLLmZA== X-Received: by 2002:a05:6870:4617:b0:de:44ca:5e52 with SMTP id z23-20020a056870461700b000de44ca5e52mr3215007oao.170.1650682770445; Fri, 22 Apr 2022 19:59:30 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id u144-20020acaab96000000b00324edac04f2sm1037012oie.37.2022.04.22.19.59.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Apr 2022 19:59:29 -0700 (PDT) Date: Fri, 22 Apr 2022 19:59:27 -0700 From: Noah Misch To: Robert Haas , Thomas Munro Cc: Andrew Dunstan , Tom Lane , PostgreSQL Hackers Subject: Re: pgsql: Allow db.schema.table patterns, but complain about random garbag Message-ID: <20220423025927.GA1274057@rfd.leadboat.com> References: <3a190754-b2b0-d02b-dcfd-4ec1610ffbcb@dunslane.net> <3687648.1650636245@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Apr 23, 2022 at 09:12:20AM +1200, Thomas Munro wrote: > On Sat, Apr 23, 2022 at 8:06 AM Robert Haas wrote: > > I have to say the fact that IPC::Run does shell-glob expansion of its > > arguments on some machines and not others seems ludicrous to me. This > > patch may be overtested, but such a radical behavior difference is > > completely nuts. How is anyone supposed to write reliable tests for > > any feature in the face of such wildly inconsistent behavior? The MinGW gcc crt*.o files do shell-glob expansion on the arguments before entering main(). See https://google.com/search?q=mingw+command+line+glob for various discussion of that behavior. I suspect you experienced that, not any IPC::Run behavior. (I haven't tested, though.) Commit 11e9caf likely had the same cause, though the commit message attributed it to the msys shell rather than to crt*.o. Let's disable that MinGW compiler behavior. https://willus.com/mingw/_globbing.shtml lists two ways of achieving that. > Yeah, I was speculating that it's a bug in IPC::Run that has been > fixed (by our very own Noah), and some of the machines are still > running the buggy version. That change affected arguments containing double quote characters, but mere asterisks shouldn't need it. It also has not yet been released, so few or no buildfarm machines are using it. > (Not a Windows person, but I speculate the reason that such a stupid > bug is even possible may be that Windows lacks a way to 'exec' stuff > with a passed-in unadulterated argv[] array, so you always need to > build a full shell command subject to interpolation, so if you're > trying to emulate an argv[]-style interface you have to write the code > to do the escaping, and so everyone gets a chance to screw that up.) You needn't involve any shell. Other than that, your description pretty much says it. CreateProcessA() is the Windows counterpart of execve(). There's no argv[] array, just a single string. (The following trivia does not affect PostgreSQL.) Worse, while there's a typical way to convert that string to argv[] at program start, some programs do it differently. You need to know your callee in order to construct the string: https://github.com/toddr/IPC-Run/pull/148/commits/c299a86c9a292375fbfc39fb756883c80adac4b0#diff-5833a343d19ba684779743e2c90516fc65479609274731785364d2d2b49e2211