Re: Improve tab completion for various SET/RESET forms

Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>

From: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers@postgresql.org
Date: 2025-06-11T10:06:42Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix tab completion for ALTER ROLE|USER ... RESET

  2. Schema-qualify unnest() in ALTER DATABASE ... RESET

Peter Eisentraut <peter@eisentraut.org> writes:

> On 09.06.25 22:27, Dagfinn Ilmari Mannsåker wrote:
>> I noticed that psql tab-completes every possible session-settable
>> variable after RESET, not just the ones that have actually been set in
>> the current session.  However, as I was fixing that I noticed several
>> other deficiencies around other forms of SET/RESET.  So, here's the
>> resulting yak stack.
>
> These technical changes seem fine, but I haven't looked in detail.  But
> I want to say that I don't like this proposed behavior change at all.

This is not the first case of behaviour like this: there's precedence
for it for ALTER DATABASE ... RESET and ALTER ROLE ... RESET (but that
was buggy and is fixed by the first patch in the series): they only
complete variables that are actually set on the relevant entity. See the
thread at
https://postgr.es/m/CAEP4nAzqiT6VbVC5r3nq5byLTnPzjniVGzEMpYcnAHQyNzEuaw%40mail.gmail.com

Why should the session be any different?

> don't think tab completion should filter out by things that are probably
> not interesting or useful depending on session state.  That could be 
> very confusing, especially since there is no surface to explain this
> anywhere.  The obvious extreme case is that RESET in a fresh session 
> wouldn't offer any completions at all.

That's not the case, as mentioned in the commit message for the final
patch: it also completes with the keywords ALL, ROLE and SESSION (which
will subsequently be completed with AUTHORIZATION).

Also, it's a handy way of seeing which variables have been set in the
current session, withouth having to query pg_settings manually.

- ilmari