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 1nigpp-0008Kg-8p for pgsql-hackers@arkaria.postgresql.org; Sun, 24 Apr 2022 18:19:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nigpm-00066t-5O for pgsql-hackers@arkaria.postgresql.org; Sun, 24 Apr 2022 18:19:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nigpl-00066b-Ga for pgsql-hackers@lists.postgresql.org; Sun, 24 Apr 2022 18:19:45 +0000 Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nigpe-0004T1-7E for pgsql-hackers@lists.postgresql.org; Sun, 24 Apr 2022 18:19:44 +0000 Received: by mail-ot1-x330.google.com with SMTP id w27-20020a056830061b00b00604cde931a0so9357471oti.2 for ; Sun, 24 Apr 2022 11:19:38 -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=Pyhh0jWC2Wdq/0IFUVp/sIxFw52AgFPOJ4YfP9dIAV4=; b=KzG+LEN7Uaeq32DdJHRhZMj0f/mIp+LKmaNrV2S6en5I7aZZrds0a7PPswQalakpnR 5eLMoxTU/ptaXXvnAm6ytxUee3k/57pGfiaPTTRKPs7bGDOil4fhHmMtFwWFtk4I9iCl Wg8E0b2Ircm2UzZl/aylSyh64EKf17IGFBrps= 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=Pyhh0jWC2Wdq/0IFUVp/sIxFw52AgFPOJ4YfP9dIAV4=; b=n5lWlNlbB9RR523JjIo/HzI008KWsjWxRHjFuEO03/yOIwuAL1gGlGcZTk/6Y7y7e9 dv+IVrXqTZQhf88BG2D7p2NeuQsT24vRyVdZrzRfn6IPGi1VED2k6nqgzHrPNtnXBAb8 F4oTWnhcgOgj9aeCx8t1CWOZneUrgNCr1/e9E3DtwV89sv0UrTiGvdlUvaRHRPnAoXz/ wDI/VpiGxXspLTKD0upeZwBHYCqjLS7Q9ObGCqb9ZQtUKsOdXCdVjc60JaoHRYUs+ZfF KdQXb5sHJV8nuj5FIFZunFjzaT4WdPRIkcVDg1dD/jCGgXXhbxvzmOUYl8jHL3ZLosZt jymA== X-Gm-Message-State: AOAM533gAPdA0Fl6W/sqWoD6oB9Iq731dnmNvabJBLDui+6l+tEnNy+f DICOKUOdlF1uHwTG8VqI14kH/A== X-Google-Smtp-Source: ABdhPJwJSxCMRYiIN575UM0J3xYF/GGtsq6DuV/2jVTfcc4Nl3lnXYiJf4AqxFC3qyeojn72QICS1Q== X-Received: by 2002:a9d:6c15:0:b0:605:4ae7:f878 with SMTP id f21-20020a9d6c15000000b006054ae7f878mr5177421otq.243.1650824377299; Sun, 24 Apr 2022 11:19:37 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id u20-20020a4a9e94000000b003291f6ac4b2sm3395053ook.28.2022.04.24.11.19.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Apr 2022 11:19:36 -0700 (PDT) Date: Sun, 24 Apr 2022 11:19:34 -0700 From: Noah Misch To: Andrew Dunstan Cc: Robert Haas , Thomas Munro , Tom Lane , PostgreSQL Hackers Subject: Re: pgsql: Allow db.schema.table patterns, but complain about random garbag Message-ID: <20220424181934.GA1326154@rfd.leadboat.com> References: <3a190754-b2b0-d02b-dcfd-4ec1610ffbcb@dunslane.net> <3687648.1650636245@sss.pgh.pa.us> <20220423025927.GA1274057@rfd.leadboat.com> <22c77d3c-3f90-2451-1f95-ed0d3e196d81@dunslane.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22c77d3c-3f90-2451-1f95-ed0d3e196d81@dunslane.net> 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 Sun, Apr 24, 2022 at 01:09:08PM -0400, Andrew Dunstan wrote: > On 2022-04-22 Fr 22:59, Noah Misch wrote: > > 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 can definitely confirm that this is the proximate cause of the > issue, and not either IPC::Run or the shell, which is why all my > experiments on this failed. With this patch Thanks for confirming. > diff --git a/src/include/port/win32.h b/src/include/port/win32.h > index c6213c77c3..456c3f31f1 100644 > --- a/src/include/port/win32.h > +++ b/src/include/port/win32.h > @@ -77,3 +77,7 @@ struct sockaddr_un > char sun_path[108]; > }; > #define HAVE_STRUCT_SOCKADDR_UN 1 > + > +#ifndef _MSC_VER > +extern int _CRT_glob = 0; /* 0 turns off globbing; 1 turns it on */ > +#endif > > > fairywren happily passes the tests that Robert has since reverted. > > > I'm rather tempted to call this CRT behaviour a mis-feature, especially > as a default. I think we should certainly disable it in the development > branch, and consider back-patching it, although it is a slight change in > behaviour, albeit one that we didn't know about much less want or > document. Still, we been building with mingw compilers for about 20 > years and haven't hit this before so far as we know, so maybe not. I'd lean toward back-patching. We position MSVC and MinGW as two ways to build roughly the same PostgreSQL, not as two routes to different user-facing behavior. Since the postgresql.org/download binaries use MSVC, aligning with their behavior is good. It's fair to mention in the release notes, of course. Does your win32.h patch build without warnings or errors? Even if MinGW has some magic to make that work, I suspect we'll want a non-header home. Perhaps src/common/exec.c? It's best to keep this symbol out of libpq and other DLLs, though I bet exports.txt would avoid functional problems.