Replace literal 0 values with the appropriate Invalid* constants
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:t53300psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 17, 2026 at 01:21 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 t53300_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 t53300_1 && git checkout t53300_1Patchset v1 (message #1) is on t53300_1
Hi hackers,
There are some places where we are using literal 0 instead of the proper Invalid*
constant.
I think it's better to use the proper constant instead: It improves code clarity
by making it explicit that these are invalid values rather than ambiguous zero
literals.
We already did the exercise for InvalidXLogRecPtr in ec317440716 and the same has
been proposed for InvalidReplOriginId in [1]/messages/by-id/tencent_FED33DE297DEA5EC5E888D3B9F7E50D6EF07@qq.com.
In this patch series I focused on the output of 'git grep "#define Invalid" "*.h"'
where invalid values are defined as 0.
That gives:
0001: Dealing with InvalidMultiXactId
That's not a lot of noise:
1 file changed, 1 insertion(+), 1 deletion(-)
0002: Dealing with InvalidOffsetNumber
That's not a lot of noise:
6 files changed, 7 insertions(+), 7 deletions(-)
0003: Dealing with InvalidAttrNumber
A bit more noise but I think it's still manageable to review:
19 files changed, 38 insertions(+), 37 deletions(-)
0004: Dealing with InvalidDsaPointer
That's not a lot of noise:
1 file changed, 1 insertion(+), 1 deletion(-)
0005: Dealing with InvalidRelFileNumber
That's not a lot of noise:
3 files changed, 5 insertions(+), 5 deletions(-)
Overall that's:
30 files changed, 52 insertions(+), 51 deletions(-)
If we think those changes are worth it, then I think that's not that much noise
(and that could be merged at an interval of choice if we feel that's too much noise).
FWIW, the same kind of Coccinelle script that lead to ec317440716 has been used
to generate those patches.
[1]: /messages/by-id/tencent_FED33DE297DEA5EC5E888D3B9F7E50D6EF07@qq.com
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachments:
t53300_1v1-0001-Replace-literal-0-with-InvalidMultiXactId-for-Mul.patchtext/x-diff; charset=us-asciiDownload+1-2
v1-0002-Replace-literal-0-with-InvalidOffsetNumber-for-Of.patchtext/x-diff; charset=us-asciiDownload+7-8
v1-0003-Replace-literal-0-with-InvalidAttrNumber-for-Attr.patchtext/x-diff; charset=us-asciiDownload+38-38
v1-0004-Replace-literal-0-with-InvalidDsaPointer-for-dsa_.patchtext/x-diff; charset=us-asciiDownload+1-2
v1-0005-Replace-literal-0-with-InvalidRelFileNumber-for-R.patchtext/x-diff; charset=us-asciiDownload+5-6
Hi,
On 2026-02-12 10:15:06 +0000, Bertrand Drouvot wrote:
There are some places where we are using literal 0 instead of the proper Invalid*
constant.I think it's better to use the proper constant instead: It improves code clarity
by making it explicit that these are invalid values rather than ambiguous zero
literals.
I think we should reject these and other similar patches, they generate way
more noise than they are improving the code. If you edit the code for other
reasons and update the initialization in the course of that, ok, but these
wholesale searches for initializing with 0 use up bandwidth that we could use
for much more worthwhile things.
Greetings,
Andres Freund
Hi,
On Thu, Feb 12, 2026 at 07:51:18PM -0500, Andres Freund wrote:
Hi,
On 2026-02-12 10:15:06 +0000, Bertrand Drouvot wrote:
There are some places where we are using literal 0 instead of the proper Invalid*
constant.I think it's better to use the proper constant instead: It improves code clarity
by making it explicit that these are invalid values rather than ambiguous zero
literals.I think we should reject these and other similar patches, they generate way
more noise than they are improving the code. If you edit the code for other
reasons and update the initialization in the course of that, ok, but these
wholesale searches for initializing with 0 use up bandwidth that we could use
for much more worthwhile things.
Thanks for sharing your thoughts! I'll keep using Coccinelle but only for things
that provide more "added" value to the code.
Though I thought that for things like the ones in this thread (that I agree don't
provide a lot of added value), proceding like:
(and that could be merged at an interval of choice if we feel that's too much noise).
could have been a valuable option.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com