| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Mis-use of type BlockNumber? |
| Date: | 2026-03-06 19:31:06 |
| Message-ID: | j4iku72lpbidvksioykfjiqsrehezzqfr25s6v7xvulsmfrclj@3h5qw5ct5zsb |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-03-06 10:22:10 -0500, Melanie Plageman wrote:
> 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.
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).
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-03-06 19:33:47 | Re: Trivial Fix: use palloc_array/repalloc_array for BufFile file arrays |
| Previous Message | Andres Freund | 2026-03-06 19:22:27 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |