Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB6Gb-0004cq-2t for pgsql-hackers@arkaria.postgresql.org; Wed, 17 May 2017 21:13:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dB6Ga-0008Vu-Lp for pgsql-hackers@arkaria.postgresql.org; Wed, 17 May 2017 21:13:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dB6GZ-0008U3-Jo for pgsql-hackers@postgresql.org; Wed, 17 May 2017 21:13:55 +0000 Received: from mail-qt0-x22c.google.com ([2607:f8b0:400d:c0d::22c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dB6GV-0003fX-UX for pgsql-hackers@postgresql.org; Wed, 17 May 2017 21:13:55 +0000 Received: by mail-qt0-x22c.google.com with SMTP id f55so20234481qta.3 for ; Wed, 17 May 2017 14:13:51 -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=phhTiDNADRZid/e5BPGv9nRvpQbRSeTwXWIux0+VT+4=; b=sev1Zx49olV2OPpYFd/UM0dlUiydFwo9N5PmiNeCX6Xo5lZCmL+VqCHAxYR5D5DMqg 8k3sd2TsN47I16UmxqQecwSBSvODpBXJwff5JabQPMeBWnPtsDLbqHDBccNxutAWhRxC rYm7IQC7twHRV9Sl/fjDP0BIq2UMs9E7rGntITjlNNCT1FSLGYjAoCg9hiCSg9qgpu9x fw59YQdSrU83o47r6fec6liFDoqJeJiTn9eA6ttxnd1XQVfBAlberO8eZTkPoxASmp+j EOJ3YliILTY5ec0qCQlqmKOkQwtkPTtAAMbh6P5fxj8P4/BQD6RKh+w3q4GOCX1Z+sjy LE/A== 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=phhTiDNADRZid/e5BPGv9nRvpQbRSeTwXWIux0+VT+4=; b=n5kObAYrEm7pWIjyaBXM1kd/ZgtjSEPxNZQ6EMJezFsbZkb8gl988Dn0EKYN3/qSWP YkxAlDtYCkSw8T5mJffyAen88Nq/8f5aoEwp5+yqnbXpCagE2vNuQJkBI5tiBycNmwOX Twp+NrJ41aTnGUZKWCVFKrZmal2KV4Uo63guPZ9Vs/bhGCZHhwkfC3IbAEql3/9HWYVR Cdx8lnKawVcb6O7me81NaoxG70ApTVMH2dyxgelE32N8QQU94OyicN8fcso/3v/DaN6n FksvZ+vMk0/cWFEORMUCUrOMl8beowHpop42WQpN3BAYshvgdZiSp0R7BavmgxP4Se3v WRTg== X-Gm-Message-State: AODbwcBx33JbF81sG2RPB3YHoSOKyVG02wn2jLg69I3l8ehfQ1DhkbCs cIYChvCKv6YMT2d0 X-Received: by 10.237.59.26 with SMTP id p26mr883731qte.170.1495055630080; Wed, 17 May 2017 14:13:50 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([179.57.115.10]) by smtp.gmail.com with ESMTPSA id 8sm2201895qkg.16.2017.05.17.14.13.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 14:13:49 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id CA614493; Wed, 17 May 2017 17:13:47 -0400 (-04) Date: Wed, 17 May 2017 17:13:47 -0400 From: Alvaro Herrera To: Piotr Stefaniak Cc: Peter Eisentraut , Tom Lane , "pgsql-hackers@postgresql.org" Subject: Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run. Message-ID: <20170517211347.6g2bbx2fsjffd2sz@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Piotr Stefaniak wrote: > On 2017-05-17 17:55, Peter Eisentraut wrote: > > On 5/17/17 10:14, Tom Lane wrote: > >> What I was concerned about was that pgindent will reindent the second > >> line so that it's impossible to tell whether the spacing is correct. > > > > pgindent moving string continuations to the left is a completely > > terrible behavior anyway and we should look into changing that. Just > > look at the mess it makes out of SELECT queries in pg_dump.c. > > If I remember correctly, it tries to right-align string literals to > whatever -l ("Maximum length of an output line") was set to. Yeah, it does that (for error messages too). I'm not sure what's the behavior we do want. One choice is that the continuation string opening quote should line up with the opening quote in the previous line. So for instance: elog(ERROR, "this message is very long" "and the second line may get over the 80 chars limit if we let it"); but I suppose some we would like the opening quote to line up with the parens: elog(ERROR, "this message is very long " "and the second line may get over the 80 chars limit if we let it"); I vote that the first form is best, even if it would cause me some pain because my vim config doesn't line up continuations like that. (Not sure I can tweak it to work that way.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers