Re: reprise: pretty print viewdefs - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: reprise: pretty print viewdefs |
Date | |
Msg-id | 4EF3705B.5080406@dunslane.net Whole thread Raw |
In response to | Re: reprise: pretty print viewdefs (Andrew Dunstan <andrew@dunslane.net>) |
List | pgsql-hackers |
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<andrew@dunslane.net> >> wrote: >>> The simple solution I originally proposed to put a line feed and >>> some space >>> before every target field in pretty print mode. This is a two line >>> patch. >>> The downsides are a) maybe not everyone will like the change and b) >>> it will >>> 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 >> udt_schema". >> >> 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 >> of CASE >> WHEN nco.nspname IS NOT NULL THEN current_database() >> ELSE NULL::name >> 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* cheers andrew
pgsql-hackers by date: