Re: git diff --check whitespace checks, gitattributes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: git diff --check whitespace checks, gitattributes
Date
Msg-id 28172.1383750817@sss.pgh.pa.us
Whole thread Raw
In response to Re: git diff --check whitespace checks, gitattributes  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On 11/5/13, 10:31 PM, Tom Lane wrote:
>> Maybe we should think about fixing psql to not generate that whitespace.

> Not easy, see
> http://www.postgresql.org/message-id/1285093687.5468.18.camel@vanquo.pezone.net

Ah, thanks for the reminder.  One killer point in that discussion seemed
to be that even if we got rid of the bogus whitespace in result header
lines, there might be legitimate trailing whitespace *in the result data*
--- consider SELECT 'foo '::text as an example.  So we can't install a
blanket prohibition on trailing whitespace in *.out files.  (Not that we
need one anyway, since those aren't hand-edited source; but at the time,
it was not clear --- at least not to me --- that we could apply different
check rules to different files.)

But, returning to the question of psql output pasted into SGML, it's less
clear to me that we shouldn't complain about trailing whitespace in SGML
files.  If we suppressed psql's header-line whitespace, we'd greatly ease
copying-and-pasting example output without triggering such warnings.  So
that might be a use-case that's sufficient to justify changing what psql
does.

On the third hand, there were also claims in that discussion that
third-party extensions would be annoyed if we changed psql's header
formatting, because they couldn't use the same regression output
files across PG versions.  Don't know how much weight to put on that
argument.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Recent matview push broken with -DCLOBBER_CACHE_ALWAYS
Next
From: Tom Lane
Date:
Subject: Re: git diff --check whitespace checks, gitattributes