> On Mar 7, 2026, at 03:31, Andres Freund <[email protected]> wrote:
>
> Hi,
>
> On 2026-03-06 10:22:10 -0500, Melanie Plageman wrote:
>> On Fri, Mar 6, 2026 at 9:11 AM Chao Li <[email protected]> wrote:
>>>
>>> But I think we should avoid to introduce such usages in new code. In other
>>> words, while reviewing patches, we should raise comments for such
>>> mis-usages. Is my understanding correct?
>>
>> I also don't like how BlockNumber is used this way. However, if you
>> introduce a new counter and use uint32 instead when all surrounding
>> counters are BlockNumber, it sticks out as different and is confusing.
>
> FWIW, I don't think uint32 would be a good choice. I think we're eventually
> going to have to allow larger relations and a lot of counters in uint32 would
> make that a good bit harder than right now, where it's BlockNumber. So you'd
> have to introduce a new BlockCounter type. At which point you ... can just use
> BlockNumber, or uint64 (and waste space for now).
>
Thanks for sharing your thoughts.
IMHO, the range of a counter does not have to match the range of BlockNumber,
that really depends on the context. Even if I were to do such a refactoring, I
was never thinking of replacing BlockNumber with uint32. To me, the right
choice should be an ordinary numeric type selected according to the semantics
of the value and the required range.
Similarly, there are many places that count the number of tuples, but PG does
not have a dedicated type for that, e.g. something like TupleCount. That
suggests, at least to me, that the question here is simply which ordinary
numeric type best matches the meaning of the value, rather than reusing
BlockNumber by default.
All in all, I think there is at least agreement that using BlockNumber for a
block counter is not semantically ideal, and that doing a wholesale refactoring
is probably not worthwhile. Where we seem to differ is that I think we should
avoid introducing new cases like this, and perhaps fix existing ones
opportunistically when a patch is already touching the relevant code. It sounds
like the preference is to leave it as-is for now.
I have noted this, and perhaps raise it again if there is a better opportunity
in the future.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
