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:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Real-life range datasets
Next
From: Robert Haas
Date:
Subject: Re: Escaping ":" in .pgpass - code or docs bug?