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
