| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Mis-use of type BlockNumber? |
| Date: | 2026-03-06 15:22:10 |
| Message-ID: | CAAKRu_a1WELioFMLy2UvDnbwa67Srayfb-QhhvxyABb9fW3ivw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 6, 2026 at 9:11 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> 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.
If you go and change all instances of BlockNumber being used this way
because you added one new counter, that's a lot of churn. If we decide
to change BlockNumber to a struct, we'll have a good reason and be
willing to pay the price of the churn at that point. I'm not a
stickler for consistency and in fact think it's okay to have some
things inconsistent if it means introducing new patterns that are
better. But having a single counter in a struct of the same unit as a
bunch of existing counters be a different datatype doesn't seem worth
it to me.
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-03-06 15:33:23 | Re: Rework SLRU I/O errors handle |
| Previous Message | Andrew Dunstan | 2026-03-06 15:07:30 | Allow specifying NULL default in pg_proc.dat for "any" arguments |