From: Paul Kim <mok03127@gmail.com>
To: pgsql-bugs@lists.postgresql.org,
	vismay.t@gmail.com
Cc: reshkekirill@gmail.com,
	Paul Kim <mok03127@gmail.com>
Subject: Re: BUG #19523: psql tab-completion shadows pg_db_role_setting
Date: Fri, 17 Jul 2026 23:28:47 +0900
Message-ID: <20260717142847.89731-1-mok03127@gmail.com>
In-Reply-To: 
 <CALHMmB9hbLK5cxC0Nto+YFXBhFY3pC0=LxZ=QhF_SUVWOfqnog@mail.gmail.com>
References: <19523-424457118202f570@postgresql.org>
 <CALHMmB84qkCgv3QAR78YawgfqQZCxSPkRhppxzU=e6fg8RA+AA@mail.gmail.com>
 <CALdSSPiAmy3ZoUyRXMqFazm0D0b1Y4oMhUKVpXwSBhrDh+odew@mail.gmail.com>
 <CALHMmB9hbLK5cxC0Nto+YFXBhFY3pC0=LxZ=QhF_SUVWOfqnog@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260717142847.89731-1-mok03127%40gmail.com>
Precedence: bulk

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