gcc -ftabstop option
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t46119psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 05:50 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t46119_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t46119_1 && git checkout t46119_1Patchset v1 (message #1) is on t46119_1
I suggest that we add the gcc (also clang) option -ftabstop=4.
This has two effects: First, it produces more accurate column numbers
in compiler errors and correctly indents the code excerpts that the
compiler shows with those. Second, it enables the compiler's detection
of confusingly indented code to work more correctly. (But the latter is
only a potential problem for code that does not use tabs for
indentation, so it would be mostly a help during development with sloppy
editor setups.)
Attached is a patch to discover the option in configure.
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.
Thoughts?
At Tue, 21 Jun 2022 12:49:24 +0200, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote in
I suggest that we add the gcc (also clang) option -ftabstop=4.
This has two effects: First, it produces more accurate column numbers
in compiler errors and correctly indents the code excerpts that the
compiler shows with those. Second, it enables the compiler's
detection of confusingly indented code to work more correctly. (But
the latter is only a potential problem for code that does not use tabs
for indentation, so it would be mostly a help during development with
sloppy editor setups.)Attached is a patch to discover the option in configure.
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.Thoughts?
There's no strong reason for everyone to accept that change, but I
myself don't mind whether the option is applied or not.
There was a related discussion.
/messages/by-id/BDE54C55-438C-48E9-B2A3-08EB3A0CBB9F@yesql.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.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Tue, 21 Jun 2022 12:49:24 +0200, Peter Eisentraut <peter.eisentraut@enterprisedb.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.ntt@gmail.com> writes:
There was a related discussion.
/messages/by-id/BDE54C55-438C-48E9-B2A3-08EB3A0CBB9F@yesql.seThe -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
On 21 Jun 2022, at 12:49, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
Second, it enables the compiler's detection of confusingly indented code to work more correctly.
Wouldn't we also need to add -Wmisleading-indentation for this to trigger any
warnings? Adding -ftabstop only allows the compiler to be able to properly
detect it.
--
Daniel Gustafsson https://vmware.com/
On 22.06.22 21:48, Daniel Gustafsson wrote:
On 21 Jun 2022, at 12:49, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
Second, it enables the compiler's detection of confusingly indented code to work more correctly.
Wouldn't we also need to add -Wmisleading-indentation for this to trigger any
warnings?
That is included in -Wall.