Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run. - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run.
Date
Msg-id 20170517211347.6g2bbx2fsjffd2sz@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run.  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
Responses Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Pulling up more complicated subqueries
Next
From: Noah Misch
Date:
Subject: [HACKERS] Re: Event triggers + table partitioning cause server crash incurrent master