Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation - Mailing list pgsql-hackers

From Vladimir Rusinov
Subject Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation
Date
Msg-id CAE1wr-z8ra1eyVaBHZX6qHNycn9eysXXyfPSSsi=Ht4wv_Njog@mail.gmail.com
Whole thread Raw
In response to [HACKERS] [PATCH] Remove trailing whitespaces from documentation  (Vladimir Rusinov <vrusinov@google.com>)
Responses Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation
List pgsql-hackers


On Wed, Dec 14, 2016 at 9:37 PM, Stephen Frost <sfrost@snowman.net> wrote:
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 12/14/16 12:03 PM, Stephen Frost wrote:
> > If we do want to change that, perhaps we should also change psql to not
> > output the trailing whitespace in the first place..?
>
> Previous discussion:
> https://www.postgresql.org/message-id/flat/1285093687.5468.18.camel%40vanquo.pezone.net

Thanks for that, but, frankly, it seems like most were in agreement that
we should go ahead and get rid of the trailing whitespace from psql's
output.  The last couple emails on that thread hardly seems like a
critical issue (and I'm not sure why we couldn't eliminate that
whitespace and then programmatically forbid trailing whitespace
anyway..).

Thanks for the pointer, that's quite interesting.

The real problem here, IMO, is the break in expected regression outputs.
The previous thread mainly discussed that in terms of its impact on
third-party tests using pg_regress, but for our own purposes it would be
just as nasty to need to adjust every single test case we back-patch for
the next five years.

That's funny. Linked thread is from 2010. Here we are in 2016 arguing about it (we would've done by now). :)
Looks like cost of having them around is not exactly 0.

Either way, I've attached another version of my patch - this time it avoids touching example psql output. Baby steps.
I'll let you decide on the way forward. I'm just happy to send some patches.


Overall, regression tests that compare output of psql seems like a solution not without drawbacks. I absolutely see the appeal, but this practically freezes behavior of psql and makes e.g. server tests depend not only server behavior but also on piece of irrelevant client-only code.
I could imagine a test system that is both has more-or-less human-readable expected.out files and does not depend on exact decorations added by psql.

-- 
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047

Attachment

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation