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 1pIghB-00051V-9A for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jan 2023 01:59: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 1pIgh9-0000UZ-FH for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jan 2023 01:59:55 +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 1pIgh9-0000U9-51 for pgsql-hackers@lists.postgresql.org; Fri, 20 Jan 2023 01:59:55 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pIgh6-0001WI-HL for pgsql-hackers@postgresql.org; Fri, 20 Jan 2023 01:59:53 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 48EAB3200910; Thu, 19 Jan 2023 20:59:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 19 Jan 2023 20:59:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1674179990; x=1674266390; bh=ERTTXwtuIg h8/GEprTLhll0lYIny5HVXOLrFbEfa4CI=; b=y5TdnmDzSLP0/qXnQ5VFqvOp0D 00rGyuDyd4CGk7cZuhOp2rTe5IriDO3yfeXaxU76kyzUtK+xewY07OFewfiPeaC5 B3V8vCwezqgTJlnNoLsPM7ErSg3Mv6rr6BoGhLff2ynh5wV5Q69rBewUWonxA3Ov NTHqekm3Wvj1YsUK1GBKOdRc0kh2hQSjHfP5r51OBB3aKPZXq4S2yF5sTe5X4jBf 9EZXH7ukpf9yh4MbWOYBdSQ8DwmCTuXX6J5IIuM3wonou9bE8zv3ZO68ZsqyckKf Z2OSUbquHmPtB8LHYmScoZLZHBS1bZ2yDCULYWoBlzgdoFbBwG2hLjtdDPdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1674179990; x=1674266390; bh=ERTTXwtuIgh8/GEprTLhll0lYIny 5HVXOLrFbEfa4CI=; b=HUszziKgXX7wugT9Q3fDNa1xyHY8hyucSARZW/ZoaU5H 1DtXGjjvBsjhzhRn2dtrwHiM6bB1V8X2mIH7ViEadqxq98iSSxJcCsbOUX8R2bTe AzV3GrCLOX+2yOQvTxBH4bysctgcX10RsDwWTHxYfSO4E7ieXOdEUIbz+oCHioDv AF+TPOkdUIsoeYPfcOm815/MSzRmT88kqsJKbs8yIEdD3d1VYIUh9LXM3kiCVEPN WdTK1s/HR4iH1pGime8wcxYtsN2RRRwEUrpIrcjGZzPnTd73jgpQRBrNyK4VeaN7 4KZoIJpi7hf5sJIkgCoCyYnOQddpdNCI6IVmhtj4EQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduuddggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpeetnhgurhgvshcuhfhrvghunhguuceorghnughrvghssegr nhgrrhgriigvlhdruggvqeenucggtffrrghtthgvrhhnpedvffefvefhteevffegieetfe fhtddvffejvefhueetgeeludehteevudeitedtudenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Jan 2023 20:59:50 -0500 (EST) Date: Thu, 19 Jan 2023 17:59:49 -0800 From: Andres Freund To: Tom Lane Cc: pgsql-hackers@postgresql.org Subject: Re: pgindent vs variable declaration across multiple lines Message-ID: <20230120015949.vdkhzzgrd7jbwpbw@awork3.anarazel.de> References: <20230120013137.7ky7nl4e4zjorrfa@awork3.anarazel.de> <337200.1674179024@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <337200.1674179024@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2023-01-19 20:43:44 -0500, Tom Lane wrote: > Andres Freund writes: > > There's a few places in the code that try to format a variable definition like this > > > ReorderBufferChange *next_change = > > dlist_container(ReorderBufferChange, node, next); > > > but pgindent turns that into > > > ReorderBufferChange *next_change = > > dlist_container(ReorderBufferChange, node, next); > > Yeah, that's bugged me too. I suspect that the triggering factor is > use of a typedef name within the assigned expression, but I've not > tried to run it to ground. It's not that - it happens even with just int frak = 1; since it doesn't happen for plain assignments, I think it's somehow related to code dealing with variable declarations. > > I assume we'd again have to dive into pg_bsd_indent's code to fix it :( > > Yeah :-(. That's enough of a rat's nest that I've not really wanted to. > But I'd support applying such a fix if someone can figure it out. It's pretty awful code :( > > And even if we were to figure out how, would it be worth the > > reindent-all-branches pain? I'd say yes, but... > > What reindent-all-branches pain? We haven't done an all-branches > reindent in the past, even for pgindent fixes that touched far more > code than this would (assuming that the proposed fix doesn't have > other side-effects). Oh. I thought we had re-indented the other branches when we modified pg_bsd_intent substantially in the past, to reduce backpatching pain. But I guess we just discussed that option, but didn't end up pursuing it. Greetings, Andres Freund