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  (Andrew Dunstan <andrew@dunslane.net>)
Re: reprise: pretty print viewdefs  (Robert Haas <robertmhaas@gmail.com>)
Re: reprise: pretty print viewdefs  (Greg Stark <stark@mit.edu>)
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:

Previous
From: Robert Haas
Date:
Subject: Re: reprise: pretty print viewdefs
Next
From: "David E. Wheeler"
Date:
Subject: Re: Real-life range datasets