psql internals queries breaks in presence of user-defined operators
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:t248632psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 07:15 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 t248632_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 t248632_1 && git checkout t248632_1Patchset v1 (message #1) is on t248632_1
Hi!
If a user creates a malformed operator in theirs database, like:
```
create or replace function f (name, name) RETURNS boolean AS $$ begin
RETURN $1::text = $2::text; end; $$ LANGUAGE plpgsql;
CREATE OPERATOR public.!~ ( LEFTARG = name, RIGHTARG = name, FUNCTION = f);
```
then psql's meta-commands queries like \du stop working.
That's because the catalog misses operators for leftarg = name,
rightarg = name and oprname = '!~'.
I think this can be enhanced a little by schema-qualifying psql's
internal query.
While this issue is fully the user's fault, I think psql can still be
a little more conservative in operator selection, and work anyways.
PFA POC patch.
This is not a security issue, per:
https://www.postgresql.org/docs/current/app-psql.html says:
If untrusted users have access to a database that has not adopted a secure
schema usage pattern, begin your session by removing publicly-writable
schemas from search_path.
--
Best regards,
Kirill Reshke
Hi,
On Thu, 25 Jun 2026 at 12:03, Kirill Reshke <reshkekirill@gmail.com> wrote:
Hi!
If a user creates a malformed operator in theirs database, like:```
create or replace function f (name, name) RETURNS boolean AS $$ begin
RETURN $1::text = $2::text; end; $$ LANGUAGE plpgsql;
CREATE OPERATOR public.!~ ( LEFTARG = name, RIGHTARG = name, FUNCTION = f);
```then psql's meta-commands queries like \du stop working.
That's because the catalog misses operators for leftarg = name,
rightarg = name and oprname = '!~'.I think this can be enhanced a little by schema-qualifying psql's
internal query.
While this issue is fully the user's fault, I think psql can still be
a little more conservative in operator selection, and work anyways.
PFA POC patch.
Thanks for the patch!
I reviewed it and the changes look good to me.\du, \dn, \dt work
with a shadowing operation present.
Would it be worth adding a test (maybe in the psql regression suite) that
the
describe queries still return the expected rows when such an operator
exists?
Regards,
Ayush
Kirill Reshke <reshkekirill@gmail.com> writes:
If a user creates a malformed operator in theirs database, like:
...
then psql's meta-commands queries like \du stop working.
Yup.
I think this can be enhanced a little by schema-qualifying psql's
internal query.
This has been discussed and rejected before. Fully schema-qualifying
those queries would make them unreadable and close to unmaintainable.
And before you say that readability doesn't matter here: you're wrong.
Lots of people look at these queries via "psql -E" to see how to query
the catalogs.
regards, tom lane