One more bit of PL/Perl cleanup
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:t253496psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 19, 2026 at 08:52 PM.
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 t253496_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 t253496_1 && git checkout t253496_1Patchset v1 (message #1) is on t253496_1
I noticed that some places in our code test "SvOK(sv) && SvROK(sv)"
while others check just SvROK(sv). On investigation, it's clear
that SvROK implies SvOK so the first part of these tests is
pointless. I find in the Perl sources (sv.h):
#define SVf_IOK 0x00000100 /* has valid public integer value */
#define SVf_NOK 0x00000200 /* has valid public numeric value */
#define SVf_POK 0x00000400 /* has valid public pointer value */
#define SVf_ROK 0x00000800 /* has a valid reference pointer */
...
#define SVf_OK (SVf_IOK|SVf_NOK|SVf_POK|SVf_ROK| \
SVp_IOK|SVp_NOK|SVp_POK|SVpgv_GP)
...
#define SvOK(sv) (SvFLAGS(sv) & SVf_OK)
...
#define SvROK(sv) (SvFLAGS(sv) & SVf_ROK)
SvOK() is evidently intended to encode "has a defined value of any
type" while SvROK() specifically means "has a reference value".
So I think we can make our code more idiomatic and (doubtless
not measurably) faster as attached.
regards, tom lane