Peter Eisentraut <pe...@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
