> On Mar 7, 2026, at 03:31, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2026-03-06 10:22:10 -0500, Melanie Plageman wrote:
>> On Fri, Mar 6, 2026 at 9:11 AM Chao Li <li.evan.chao@gmail.com> wrote:
>>>
>>> But I think we should avoid to introduce such usages in new code. In other words, while reviewing patches, we
shouldraise 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
ifI were to do such a refactoring, I was never thinking of replacing BlockNumber with uint32. To me, the right choice
shouldbe 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.
somethinglike TupleCount. That suggests, at least to me, that the question here is simply which ordinary numeric type
bestmatches 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,
andthat doing a wholesale refactoring is probably not worthwhile. Where we seem to differ is that I think we should
avoidintroducing new cases like this, and perhaps fix existing ones opportunistically when a patch is already touching
therelevant 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/
