Typo in misc_sanity.sql?
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.
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:t46288psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:23 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 t46288_1 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 t46288_1 && git checkout t46288_1Patchset v1 (message #1) is on t46288_1
Hi, hackers
I found the misc_sanity has a SQL to check system catalogs that
do not have primary keys, however, in current exceptions it says
pg_depend, pg_shdepend don't have a unique key.
Should we fix it?
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
On Mon, Jul 25, 2022 at 1:24 PM Japin Li <japinli@hotmail.com> wrote:
Hi, hackers
I found the misc_sanity has a SQL to check system catalogs that
do not have primary keys, however, in current exceptions it says
pg_depend, pg_shdepend don't have a unique key.Should we fix it?
Indeed. There's a clear difference between primary key and unique key.
The patch LGTM.
Regards,
Bharath Rupireddy.
Japin Li <japinli@hotmail.com> writes:
I found the misc_sanity has a SQL to check system catalogs that
do not have primary keys, however, in current exceptions it says
pg_depend, pg_shdepend don't have a unique key.
As indeed they do not:
regression=# \d pg_depend
Table "pg_catalog.pg_depend"
Column | Type | Collation | Nullable | Default
-------------+---------+-----------+----------+---------
classid | oid | | not null |
objid | oid | | not null |
objsubid | integer | | not null |
refclassid | oid | | not null |
refobjid | oid | | not null |
refobjsubid | integer | | not null |
deptype | "char" | | not null |
Indexes:
"pg_depend_depender_index" btree (classid, objid, objsubid)
"pg_depend_reference_index" btree (refclassid, refobjid, refobjsubid)
regression=# \d pg_shdepend
Table "pg_catalog.pg_shdepend"
Column | Type | Collation | Nullable | Default
------------+---------+-----------+----------+---------
dbid | oid | | not null |
classid | oid | | not null |
objid | oid | | not null |
objsubid | integer | | not null |
refclassid | oid | | not null |
refobjid | oid | | not null |
deptype | "char" | | not null |
Indexes:
"pg_shdepend_depender_index" btree (dbid, classid, objid, objsubid), tablespace "pg_global"
"pg_shdepend_reference_index" btree (refclassid, refobjid), tablespace "pg_global"
Tablespace: "pg_global"
Your proposed wording seems to give strictly less information,
so I do not see why it's an improvement.
regards, tom lane
On Mon, 25 Jul 2022 at 19:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Japin Li <japinli@hotmail.com> writes:
I found the misc_sanity has a SQL to check system catalogs that
do not have primary keys, however, in current exceptions it says
pg_depend, pg_shdepend don't have a unique key.As indeed they do not:
regression=# \d pg_depend
Table "pg_catalog.pg_depend"
Column | Type | Collation | Nullable | Default
-------------+---------+-----------+----------+---------
classid | oid | | not null |
objid | oid | | not null |
objsubid | integer | | not null |
refclassid | oid | | not null |
refobjid | oid | | not null |
refobjsubid | integer | | not null |
deptype | "char" | | not null |
Indexes:
"pg_depend_depender_index" btree (classid, objid, objsubid)
"pg_depend_reference_index" btree (refclassid, refobjid, refobjsubid)regression=# \d pg_shdepend
Table "pg_catalog.pg_shdepend"
Column | Type | Collation | Nullable | Default
------------+---------+-----------+----------+---------
dbid | oid | | not null |
classid | oid | | not null |
objid | oid | | not null |
objsubid | integer | | not null |
refclassid | oid | | not null |
refobjid | oid | | not null |
deptype | "char" | | not null |
Indexes:
"pg_shdepend_depender_index" btree (dbid, classid, objid, objsubid), tablespace "pg_global"
"pg_shdepend_reference_index" btree (refclassid, refobjid), tablespace "pg_global"
Tablespace: "pg_global"
Yeah, they do not have unique keys, however, here we check primary keys. So,
IMO, the description exceptions should say they do not have primary keys,
rather than do not have unique keys.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
On 25.07.22 14:04, Japin Li wrote:
Yeah, they do not have unique keys, however, here we check primary keys. So,
IMO, the description exceptions should say they do not have primary keys,
rather than do not have unique keys.
The context of that check is that for each system catalog we pick one of
the available unique keys and designate it as the one primary key. If a
system catalog doesn't have a unique key to choose from, then we can't
do that, hence the comment. Changing the comment as suggested would
essentially be saying, this catalog has no primary key because it has no
primary key, which wouldn't be helpful.