Re: Patch to implement pg_current_logfile() function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to implement pg_current_logfile() function
Date: 2017-02-15 21:47:28
Message-ID: 17143.1487195248@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Karl O. Pinc" <kop(at)meme(dot)com> writes:
> On Wed, 15 Feb 2017 15:23:00 -0500
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I think our preferred style is not to break strings across lines like
>> this.

> How do you do that and not exceed the 80 character line limit?
> Just ignore the line length limit?

Right. It depends on context, but letting isolated lines wrap doesn't
do that much damage to readability, IMO anyway. (If you've got a bunch
of these adjacent to each other, you might choose to break them to
reduce confusion.)

The advantage of not breaking up error strings is that it makes grepping
for them more reliable, when you're wondering "where in the sources did
this error come from?". If you get a report about "could not frob a
whatzit" and grep for "frob a whatzit", but somebody decided to break
that string in the middle to avoid a line wrap, you won't find the spot.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-02-15 21:57:54 Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
Previous Message Andres Freund 2017-02-15 21:42:47 Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags