On 12/22/2011 12:52 PM, Andrew Dunstan wrote:
On 12/22/2011 12:18 PM, Robert Haas wrote:
On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan<and...@dunslane.net>
The simple solution I originally proposed to put a line feed and
before every target field in pretty print mode. This is a two line
The downsides are a) maybe not everyone will like the change and b)
produce superfluous newlines, e.g. before CASE expressions.
With regard to (a), specifically, you won't like this change if your
column names are things like "bob" and "sam", because you'll burn
through an inordinate amount of vertical space. On the other hand, I
agree that you'll probably find it a big improvement if they are
things like "nc.nspname::information_schema.sql_identifier as
It has always seemed to me that a sensible strategy here would be to
try to produce output that looks good in 80 columns, on the assumption
that (1) everyone has at least that much horizontal space to play with
and (2) people who do won't necessarily mind it if we don't use all
WHEN nco.nspname IS NOT NULL THEN current_database()
END::information_schema.sql_identifier AS collation_catalog,
nco.nspname::information_schema.sql_identifier AS collation_schema,
I'd still be much happier with a
that horizontal space when pretty-printing SQL.
However, it is possible that I am living in the dark ages.
I've looked at that, and it was discussed a bit previously. It's more
complex because it requires that we keep track of (or calculate) where
we are on the line, and where we would be after adding the new text.
But I could live with it if others could. It would certainly be an
improvement. But that's still going to leave things that will look
odd, such as a CASE expression's final line being filled up to 80
columns with more fields. My preference would be for a newline as a
visual clue to where each column spec starts.
I used to try to be conservative about vertical space, but in these
days of scrollbars and screens not limited to 24 or 25 lines (Yes,
kids, that's what some of us grew up with) that seems a bit
old-fashioned. One of the arguments for K&R style braces used to be
that it used one less line than BSD style. Maybe that made some sense
20 or so years ago, although I didn't really buy it even then, but it
makes very little sense to me now.
Wow. My editor or my fingers seem to have screwed up here. Something got
C&P'd into the middle of the quoted text that shouldn't have. *sigh*
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: