| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Type of pg_buffercache_pages()::forknum |
| Date: | 2025-11-18 06:29:57 |
| Message-ID: | aRwSZbIsZQYLsxAk@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 12, 2025 at 10:46:12AM +0530, Ashutosh Bapat wrote:
> But C implementation uses ObjectIdGetDatum() where ObjectId is 32 bit integer.
> values[4] = ObjectIdGetDatum(fctx->record[i].forknum);
>
> Since forknum values are within 16 bits and that's unlikely to change
> in future, int2 seems to ok. Also casting it to a wider integer, OID,
> also doesn't seem like a correctness issue. But it does look
> inconsistent and a reader of C implementation may think that the SQL
> datatype used is int4. Should we instead change the C Implementation
> to be
>
> values[4] = Int16GetDatum((int16) fctx->record[i].forknum);
>
> The code has been there for 17 years, and I didn't find any previous
> complaints. I propose to change just the master branch.
This just looks like a copy-pasto to me. Nice catch, will fix on
HEAD.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2025-11-18 06:32:19 | Re: nbtree VACUUM's REDO routine doesn't clear page's VACUUM cycle ID |
| Previous Message | Arseniy Mukhin | 2025-11-18 06:23:41 | Re: Use streaming read I/O in BRIN vacuuming |