[DOC] pg_database_size/pg_tablespace_size error on a missing OID
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253690psql -h localhost -U postgresBuilt from patchset v3 (message #3), September 15, 2026 at 12:35 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253690_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253690_3 && git checkout t253690_3Patchset v3 (message #3) is on t253690_3
Hi hackers,
The introduction to the database object size functions in
func-admin.sgml says that passing an OID that does not represent an
existing object returns NULL. That is true for the relation size
functions, but pg_database_size() and pg_tablespace_size() raise an
error for a nonexistent OID instead. The attached patch documents the
exception.
Thanks,
Shihao
On Sep 5, 2026, at 21:11, shihao zhong <zhong950419@gmail.com> wrote:
Hi hackers,
The introduction to the database object size functions in
func-admin.sgml says that passing an OID that does not represent an
existing object returns NULL. That is true for the relation size
functions, but pg_database_size() and pg_tablespace_size() raise an
error for a nonexistent OID instead. The attached patch documents the
exception.Thanks,
Shihao
<0001-doc-note-that-pg_database_size-and-pg_tablespace_siz.patch>
The change overall looks good to me. One nitpick:
```
+ functions, <literal>NULL</literal> is returned, except by
```
“Except by” sounds uncommon, is “expect for” better?
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Hi Chao,
Thanks for reviewing that.
“Except by” sounds uncommon, is “expect for” better?
Updated.
Thanks,
Shihao
On Sep 8, 2026, at 08:06, shihao zhong <zhong950419@gmail.com> wrote:
Hi Chao,
Thanks for reviewing that.
“Except by” sounds uncommon, is “expect for” better?
Updated.
Thanks,
Shihao
<v2-0001-doc-note-that-pg_database_size-and-pg_tablespace_siz.patch>
V2 looks good to me.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Hi,
I reviewed and tested the v2 patch.
I first verified the existing behavior with a nonexistent OID:
-pg_database_size(999999) returns an error saying the database does not exist.
-pg_tablespace_size(999999) returns an error saying the tablespace
does not exist.
I then applied the v2 patch. It applied cleanly, and git diff --check
reported no issues.
After applying the patch, I repeated the same tests and confirmed that
the behavior remains unchanged. I also tested valid database and
tablespace OIDs, and both returned the expected size values.
From my testing, the patch correctly documents the existing exception
without changing the runtime behavior.
The v2 patch looks good to me.
Thanks,
solai
On 10 Sep 2026, at 07:27, solai v <solai.cdac@gmail.com> wrote:
I reviewed and tested the v2 patch.
This indeed seems like a low-effort fix for this inconsistency which will need
to be backpatched into all supported branches. I can't see why we have this
inconsistency though, there is no technical reason behind it. Maybe we should
look at changing this in 20 to make all these functions behave the same?
I'll push the documentation fixup in the meantime though, as this is affecting
published branches.
--
Daniel Gustafsson