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 1jP6CH-0002lV-PA for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2020 15:12:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jP6CG-00072K-Lo for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2020 15:12:56 +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 1jP6CG-00072D-Ez for pgsql-hackers@lists.postgresql.org; Thu, 16 Apr 2020 15:12:56 +0000 Received: from mail-qk1-x743.google.com ([2607:f8b0:4864:20::743]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jP6CD-0007X1-GX for pgsql-hackers@postgresql.org; Thu, 16 Apr 2020 15:12:56 +0000 Received: by mail-qk1-x743.google.com with SMTP id l25so21636841qkk.3 for ; Thu, 16 Apr 2020 08:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=drOzRGEI2RmIT1VcPiplT6717zWFc/j/vmG+EIkYi9Y=; b=XETLYQAgoBIDphaBgHx0mpV6J16IPYNTqVuI69un9GUN9TE2D8B5ySXjCn8IdBLIDg jbR1Txd3y2Cg48u6pTkb6MJqmrCivlUkunY1vL86dwMNAZC/odjzFU70c1S29lGfQ3om fgShF1d7H53hTsNq3jte3qcxtSOTn6NBITjfkEx2zgNFxdPQXEktZZb/nxd2CIZekr9U xq3B1wFGVx71XYTZ9RC9+kZ8URAHxYEEJtalYO24NuyuPClo7RiZ/hJCR0EvKA1JlrMS keQ8IxS6vtiizY8ZyMN2fpq5uxuy0TJZEyF/I8ATFmWKqBGmjQQZ1/uWPe6bzJgsAh+Z 3A4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=drOzRGEI2RmIT1VcPiplT6717zWFc/j/vmG+EIkYi9Y=; b=jZrJNL5+4LN0UGRGrHf30Tqngbvlh3H3La6wskSQN1b4Vu6y3PUz7E9Lcd2aw3PfEU o6MnN94vmD5SRqjVac+rD8l1COztsSXHkT69OA0uTQz6V+yiqH6Bja2TdK6TGootZ3ld GRKIFHdO1KUbvrMnyJDES1hR7xGNKZotQC9CKqHqH3z7aO2J8iNvs85oS2Mk/NQCPxxk yj+5rQvVhJXnpd4csaZW3gW3a39vnUtGXnxPar4dNZ0UxVYlqGjEGVg33itwUG2XbVON om+Z37ixqF5SbPsdJl60o7vKrxklODaaIlgKHgtupKm7l7XeZ8U2sQC8AR8QpSUweBP0 2MoA== X-Gm-Message-State: AGi0PuaRZz5t+orx47YfNTmI/4o4O4IEK+A299TKi5fPOvDl1mtdll9E u1C7MslLZ4tk9VY8tYU/HPKeMA== X-Google-Smtp-Source: APiQypJKC8jEDZX8MzEa/V8TtJ5ZFOW/03PBOiiXFKp/xSVgcCzoHyDMWZlLXA3NkdBTXfKj47JZkA== X-Received: by 2002:ae9:efc8:: with SMTP id d191mr31885402qkg.31.1587049971536; Thu, 16 Apr 2020 08:12:51 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id 29sm6765471qkr.109.2020.04.16.08.12.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2020 08:12:50 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id D60D93007D1; Thu, 16 Apr 2020 11:12:48 -0400 (-04) Date: Thu, 16 Apr 2020 11:12:48 -0400 From: Alvaro Herrera To: "Hamlin, Garick L" Cc: Andrew Dunstan , Noah Misch , PostgreSQL-development Subject: Re: cleaning perl code Message-ID: <20200416151248.GA8282@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200416142052.zqtgtiubaf6fycn2@isc.upenn.edu> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Apr-16, Hamlin, Garick L wrote: > With the old expression 'something;' would be stripped away. > Is that an issue where this this is used? Why are we parsing > these headers? These are files from which bootstrap catalog data is generated, which is why we parse from Perl; but also where C structs are declared, which is why they're C. I think switching to non-greedy is a win in itself. Non-capturing parens is probably a wash (this doesn't run often so the performance argument isn't very interesting). An example. This eval in Catalog.pm + ## no critic (ProhibitStringyEval) + ## no critic (RequireCheckingReturnValueOfEval) + eval '$hash_ref = ' . $_; is really weird stuff generally speaking, and the fact that we have to mark it specially for critic is a good indicator of that -- it serves as documentation. Catalog.pm is all a huge weird hack, but it's a critically important hack. Heck, what about RequireCheckingReturnValueOfEval -- should we instead consider actually checking the return value of eval? It would seem to make sense, would it not? (Not for this patch, though -- I would be fine with just adding the nocritic line now, and removing it later while fixing that). All in all, I think it's a positive value in having this code be checked with a bit more strength -- checks that are pointless in, say, t/00*.pl prove files. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services