Tom Lane wrote:
> Greg Stark <gsstark@mit.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
