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

From Tom Lane
Subject Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.
Date
Msg-id 12243.1495058125@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Piotr Stefaniak wrote:
>> 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).

Piotr's version seems to at least do this more consistently than the
old version; for instance I notice this diff from Bruce's run:

@@ -1864,8 +1864,8 @@ describeOneTableDetails(const char *schemaname,       if (verbose)
printfPQExpBuffer(&buf,                            "SELECT inhparent::pg_catalog.regclass,"
 
-                           "       pg_get_expr(c.relpartbound, inhrelid),"
-                         "     pg_get_partition_constraintdef(inhrelid)"
+                             "     pg_get_expr(c.relpartbound, inhrelid),"
+                             "     pg_get_partition_constraintdef(inhrelid)"                             " FROM
pg_catalog.pg_classc"                             " JOIN pg_catalog.pg_inherits"                             " ON c.oid
=inhrelid"
 

(Again, untabified for clarity.)  However, it didn't do anything to any of
the horribly-formatted queries in pg_dump.c, so it's mostly following the
same rule as before.

> 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:

Yeah, I'd vote for that one too.  If you want to line things up with
a function call paren, you can always start the whole literal on a fresh
line, as in the above example.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)