Re: Fix signed/unsigned integer handling in pg_restore_relation_stats()

> On Aug 18, 2026, at 16:36, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> The pg_class fields relpages, relallvisible, and relallfrozen are of
> type int32, but the statistics restoration code internally dealt with them as uint32 for a little bit, after which they would turn back into int32. This all happens to work, but it doesn't make sense, so I propose the attached fix.
>
> While researching this, I noticed that we don't appear to document how page/block counts larger than INT32_MAX are represented in the catalogs. A C programmer would have a certain expectation, but we shouldn't expect everyone to guess that. So I'm proposing a small addition to the catalog documentation to clarify this.
> <0001-Fix-signed-unsigned-integer-handling-in-pg_restore_r.patch><0002-doc-Document-overflow-handling-of-pg_class.relpages-.patch>

Overall looks good to me. Only one small comment on 0001:
```
--- a/src/backend/statistics/relation_stats.c
+++ b/src/backend/statistics/relation_stats.c
@@ -99,13 +99,13 @@ relation_statistics_update(FunctionCallInfo fcinfo)
static bool
relation_statistics_update_internal(Oid reloid, FunctionCallInfo fcinfo)
{
- BlockNumber relpages = 0;
+ int32 relpages = 0;
```

relpages is changed to int32, so the later code of PG_GETARG_UINT32(RELPAGES_ARG) to PG_GETARG_INT32.
```
if (!PG_ARGISNULL(RELPAGES_ARG))
{
relpages = PG_GETARG_UINT32(RELPAGES_ARG);
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/