Re: gcc -ftabstop option

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: peter(dot)eisentraut(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: gcc -ftabstop option
Date: 2022-06-22 00:48:12
Message-ID: 3143909.1655858892@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> At Tue, 21 Jun 2022 12:49:24 +0200, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote in
>> One bit of trickery not addressed yet is that we might want to strip
>> out the option and not expose it through PGXS, since we don't know
>> what whitespacing rules external code uses.

This part seems like a bigger problem than the option is worth.
I agree that we can't assume third-party code prefers 4-space tabs.

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> There was a related discussion.
> https://www.postgresql.org/message-id/BDE54C55-438C-48E9-B2A3-08EB3A0CBB9F%40yesql.se
>> The -ftabstop option is (to a large extent, not entirely) to warn when tabs and
>> spaces are mixed creating misleading indentation that the author didn't even
>> notice due to tabwidth settings? ISTM we are better of getting these warnings
>> than suppressing them.

Isn't that kind of redundant given that (a) we have git whitespace
warnings about this and (b) pgindent will take care of any such
problems in the end?

I'll grant the point about compiler warnings possibly not lining up
precisely. But that's yet to bother me personally, so maybe I'm
underestimating its value.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-06-22 01:04:05 Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Previous Message Kyotaro Horiguchi 2022-06-22 00:36:05 Re: gcc -ftabstop option