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].
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]: https://postgr.es/m/tencent_FED33DE297DEA5EC5E888D3B9F7E50D6EF07%40qq.com
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
