Re: BUG #19523: psql tab-completion shadows pg_db_role_setting

From: Paul Kim <mok03127(at)gmail(dot)com>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org, vismay(dot)t(at)gmail(dot)com
Cc: reshkekirill(at)gmail(dot)com, Paul Kim <mok03127(at)gmail(dot)com>
Subject: Re: BUG #19523: psql tab-completion shadows pg_db_role_setting
Date: 2026-07-17 14:28:47
Message-ID: 20260717142847.89731-1-mok03127@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Vismay,

I had a look at the v1 patch, looks good to me.

Query_for_list_of_database_vars really is the only completion query still
referencing catalogs unqualified -- split_part()/unnest() right next to it
are already pg_catalog-qualified, and the sibling queries
(Query_for_list_of_databases, _tablespaces, ...) all qualify theirs too, so
this just brings it in line.

I reproduced it on master with a shadowing table:

CREATE SCHEMA s;
CREATE TABLE s.pg_db_role_setting (setdatabase oid, setrole oid, setconfig text[]);
INSERT INTO s.pg_db_role_setting
SELECT oid, 0, ARRAY['evil_var=x'] FROM pg_catalog.pg_database
WHERE datname = 'postgres';
SET search_path = s, pg_catalog;

Before the patch the query hands back 'evil_var'; after qualifying both
catalogs it returns nothing, and a real ALTER DATABASE ... SET still shows up
fine. Applies and builds cleanly here.

On back-patching: the macro came in with v18 (9df8727c50), it's in
REL_18_STABLE and master but not REL_17, so v18 + master matches what you
said.

Agreed on leaving out a test -- the completion queries aren't covered by TAP
anyway.

One small nit, and it's not really about the code: since we've settled that
this is more of a consistency/robustness thing than a security issue, the
commit message's "feeds arbitrary values" wording could probably be toned
down, but that's the committer's call.

Looks ready for committer to me.

Regards,
Paul

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Matheus Alcantara 2026-07-17 15:05:06 Re: BUG #19553: Wrong results from nested LEFT JOINs over an empty subquery (regression since v16)
Previous Message Peter Eisentraut 2026-07-17 14:25:18 Re: BUG #19548: Missing dependency between a graph edge and the related PK