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
>> 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 ...
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2009-08-26 22:51:33|
|Subject: Re: MySQL Compatibility WAS: 8.5 release timetable, again|
|Previous:||From: Guillaume Smet||Date: 2009-08-26 22:48:50|
|Subject: Re: 8.5 release timetable, again|