Re: Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET - Mailing list pgsql-hackers

From Dagfinn Ilmari Mannsåker
Subject Re: Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET
Date
Msg-id 875xfahtik.fsf@wibble.ilmari.org
Whole thread Raw
In response to Re: Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET  (Tomas Vondra <tomas@vondra.me>)
Responses Re: Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET
List pgsql-hackers
Tomas Vondra <tomas@vondra.me> writes:

> On 7/22/25 13:18, Dagfinn Ilmari Mannsåker wrote:
>> jian he <jian.universality@gmail.com> writes:
>> 
>>> On Thu, Jul 17, 2025 at 1:41 AM Dagfinn Ilmari Mannsåker
>>> <ilmari@ilmari.org> wrote:
>>>>
>>>> Hi hackers,
>>>>
>>>> These two patches are split out from my earlier thread about improving
>>>> tab completion for varous RESET forms
>>>> (https://postgr.es/m/87bjqwwtic.fsf@wibble.ilmari.org), so that the bug
>>>> fixes can be tracked as an open item for v18.
>>>>
>>>> Commits 9df8727c5067 and c407d5426b87 added tab completion for ALTER
>>>> DATABASE ... RESET and ALTER ROLE/USER ... RESET, respectively, but
>>>> they're both differently buggy.  The query for the DATABASE form
>>>> neglected to schema-qualify the unnest() call, and the query for the
>>>> ROLE/USER form shows all possible variables once you start typing a
>>>> variable name, not just the ones that are set on the role.  The attached
>>>> patches fix both.
>>>>
>>>
>>> I played around with it, and overall it looks good.
>> 
>> Thanks for the review.
>> 
>> I realise I should have included Robins and Tomas in the original mail,
>> since they were the author and committer, respectively, of the original
>> patches.  I've added them now, and reattached the patches for their
>> convenience.
>> 
>
> Thanks for the fixes. Both seem correct to me. It took me a while to
> reproduce some sort of issue with unnest(), but that was mostly because
> I didn't realize the tab completion does not report errors to the user.
>
> While testing the ALTER ROLE part, I realized there's a second related
> issue with similar symptoms - after starting to type a variable that is
> *not* set for the role, it was offering all matching variables anyway. I
> believe that's because of the block at line ~5022. The "database" case
> was already excluded, so I made 0002 to do that for ROLE too.

Ah, good catch, I missed that edge case.

> @@ -5015,7 +5021,8 @@ match_previous_words(int pattern_id,
>      /* Complete with a variable name */
>      else if (TailMatches("SET|RESET") &&
>               !TailMatches("UPDATE", MatchAny, "SET") &&
> -             !TailMatches("ALTER", "DATABASE", MatchAny, "RESET"))
> +             !TailMatches("ALTER", "DATABASE", MatchAny, "RESET") &&
> +             !TailMatches("ALTER", "USER|ROLE", MatchAny, "RESET"))
>          COMPLETE_WITH_QUERY_VERBATIM_PLUS(Query_for_list_of_set_vars,
>                                            "CONSTRAINTS",
>                                            "TRANSACTION",

Instead of adding another !TailMatches() call, why not just change
"DATABASE" to "DATABASE|ROLE|USER"?

- ilmari



pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Automatically sizing the IO worker pool
Next
From: Nazir Bilal Yavuz
Date:
Subject: Re: Improve prep_buildtree