Skip site navigation (1) Skip section navigation (2)

Re: pretty print viewdefs

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, decibel <decibel(at)decibel(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pretty print viewdefs
Date: 2009-08-26 22:49:27
Message-ID: 4A95BBF7.7020301@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>   
>> I agree with Tom's concerns -- think of that guy who was bumping up
>> against the 1600 column limit. At least if they're on one line you can
>> still see the structure of the query albeit with a very very wide
>> scrollbar...
>>     
>
>   
>> But for typical queries I do agree one per line is better. That is
>> actually how I format my queries when they have complex expressions in
>> the target list. Perhaps formatting one per line whenever there's an
>> alias or the value is a complex expression but putting any unaliased
>> columns (such as produced by select *) in a single line would be a
>> good compromise?
>>     
>
> Yeah, I was wondering about adopting some rule like that too.
>
> It would be pretty easy to adjust that loop so that columns that aren't
> simple Vars are put on their own line, while Vars are allowed to share
> a line.  I dunno whether users would see that as inconsistent, though.
>   


Yeah, probably, I don't like it much.

I do have a solution that wraps when running line length over 80 instead 
of on every col:

 SELECT sh.shoename, sh.sh_avail, sh.slcolor, sh.slminlen,
    sh.slminlen * un.un_fact AS slminlen_cm, sh.slmaxlen,
    sh.slmaxlen * un.un_fact AS slmaxlen_cm, sh.slunit
   FROM shoe_data sh, unit un
  WHERE sh.slunit = un.un_name;


It's not a huge amount of code.

Maybe we need a couple of extra pg_get_viewdef() variants. One to wrap 
on some provided line length, one to wrap on every column. psql could 
use the first, pg_dump could use the second.

I really can't believe anyone wants a single line with 1600 column specs ...

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2009-08-26 22:51:33
Subject: Re: MySQL Compatibility WAS: 8.5 release timetable, again
Previous:From: Guillaume SmetDate: 2009-08-26 22:48:50
Subject: Re: 8.5 release timetable, again

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group