Alvaro Herrera <alvhe...@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_class c" " 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers