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
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 |