Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...

From: VASUKI M <vasukianand0119(at)gmail(dot)com>
To: zengman <zengman(at)halodbtech(dot)com>
Cc: Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, surya poondla <suryapoondla4(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dharin Shah <dharinshah95(at)gmail(dot)com>
Subject: Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...
Date: 2026-01-06 10:54:22
Message-ID: CAE2r8H76TK9eofqLuO5n2g=E8i3LM4QW95KZzuvsipDJvfAdKg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thanks for taking a closer look — that’s a fair question.

The guard is not meant to protect exec_query(), but rather the calls to
PQescapeLiteral(), which are executed before COMPLETE_WITH_QUERY_PLUS
and therefore before exec_query() is reached.

In this code path we construct the query string by calling
PQescapeLiteral(pset.db, ...) directly, and that function assumes a
non-NULL, valid PGconn. If pset.db is NULL or the connection is not in
CONNECTION_OK state, calling PQescapeLiteral() would be unsafe and could
lead to a crash before exec_query() has a chance to handle anything.

The fallback to COMPLETE_WITH("ALL") is intended as a safe default, matching
existing RESET completion behavior when no catalog information can be
retrieved.

That said, I agree it’s worth double-checking whether pset.db is always
guaranteed to be valid in this context, and I’m happy to refine or document
this further if you think a different approach would be better.

Thanks for flagging this .

Regards,
Vasuki M
C-DAC,Chennai

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2026-01-06 11:02:36 Re: WIP - xmlvalidate implementation from TODO list
Previous Message zengman 2026-01-06 10:46:48 Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ...