Re: reprise: pretty print viewdefs - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: reprise: pretty print viewdefs |
Date | |
Msg-id | 4EF36E58.7030501@dunslane.net Whole thread Raw |
In response to | Re: reprise: pretty print viewdefs (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: reprise: pretty print viewdefs
Re: reprise: pretty print viewdefs Re: reprise: pretty print viewdefs |
List | pgsql-hackers |
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 AScollation_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. cheers andrew
pgsql-hackers by date: