| 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
| 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 |