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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
