From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reprise: pretty print viewdefs |
Date: | 2011-12-22 17:52:24 |
Message-ID: | 4EF36E58.7030501@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/22/2011 12:18 PM, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan<andrew(at)dunslane(dot)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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-12-22 17:58:22 | Re: Real-life range datasets |
Previous Message | Robert Haas | 2011-12-22 17:18:54 | Re: reprise: pretty print viewdefs |