Re: [PATCH]Feature improvement for MERGE tab completion

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: [PATCH]Feature improvement for MERGE tab completion
Дата
Msg-id CAEZATCUdBsHsbpdu2XasSVTM0bLf5Ag+zg-4raBndPkwaf7esQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH]Feature improvement for MERGE tab completion  (vignesh C <vignesh21@gmail.com>)
Ответы Re: [PATCH]Feature improvement for MERGE tab completion  ("Gregory Stark (as CFM)" <stark.cfm@gmail.com>)
Список pgsql-hackers
On Tue, 3 Jan 2023 at 12:30, vignesh C <vignesh21@gmail.com> wrote:
>
> The patch does not apply on top of HEAD as in [1], please post a rebased patch:
>

This is because 0001 has been committed.
Re-uploading 0002, to keep the CF-bot happy.

Reviewing 0002...

I'm not entirely convinced that the PartialMatches() changes are
really necessary. As far as I can see USING followed by ON doesn't
appear anywhere else in the grammar, and the later completions
involving WHEN [NOT] MATCHED are definitely unique to MERGE.
Nonetheless, I guess it's not a bad thing to check that it really is a
MERGE. Also the new matching function might prove useful for other
cases.

Some more detailed code comments:

I find the name PartialMatches() a little off, since "partial" doesn't
really accurately describe what it's doing. HeadMatches() and
TailMatches() are also partial matches (matching the head and tail
parts). So perhaps MidMatches() would be a better name.

I also found the comment description of PartialMatchesImpl() misleading:

/*
 * Implementation of PartialMatches and PartialMatchesCS macros: do parts of
 * the words in previous_words match the variadic arguments?
 */

I think a more accurate description would be:

/*
 * Implementation of MidMatches and MidMatchesCS macros: do any N consecutive
 * words in previous_words match the variadic arguments?
 */

Similarly, instead of:

    /* Match N words on the line partially, case-insensitively. */

how about:

    /* Match N consecutive words anywhere on the line, case-insensitively. */

In PartialMatchesImpl()'s main loop:

        if (previous_words_count - startpos < narg)
        {
            va_end(args);
            return false;
        }

couldn't that just be built into the loop's termination clause (i.e.,
loop while startpos <= previous_words_count - narg)?

For the first block of changes using the new function:

    else if (PartialMatches("MERGE", "INTO", MatchAny, "USING") ||
             PartialMatches("MERGE", "INTO", MatchAny, "AS", MatchAny,
"USING") ||
             PartialMatches("MERGE", "INTO", MatchAny, MatchAny, "USING"))
    {
        /* Complete MERGE INTO ... ON with target table attributes */
        if (TailMatches("INTO", MatchAny, "USING", MatchAny, "ON"))
            COMPLETE_WITH_ATTR(prev4_wd);
        else if (TailMatches("INTO", MatchAny, "AS", MatchAny,
"USING", MatchAny, "AS", MatchAny, "ON"))
            COMPLETE_WITH_ATTR(prev8_wd);
        else if (TailMatches("INTO", MatchAny, MatchAny, "USING",
MatchAny, MatchAny, "ON"))
            COMPLETE_WITH_ATTR(prev6_wd);

wouldn't it be simpler to just include "MERGE" in the TailMatches()
arguments, and leave these 3 cases outside the new code block. I.e.:

    /* Complete MERGE INTO ... ON with target table attributes */
    else if (TailMatches("MERGE", "INTO", MatchAny, "USING", MatchAny, "ON"))
        COMPLETE_WITH_ATTR(prev4_wd);
    else if (TailMatches("MERGE", "INTO", MatchAny, "AS", MatchAny,
"USING", MatchAny, "AS", MatchAny, "ON"))
        COMPLETE_WITH_ATTR(prev8_wd);
    else if (TailMatches("MERGE", "INTO", MatchAny, MatchAny, "USING",
MatchAny, MatchAny, "ON"))
        COMPLETE_WITH_ATTR(prev6_wd);

Regards,
Dean

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jakub Wartak
Дата:
Сообщение: Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs
Следующее
От: Nazir Bilal Yavuz
Дата:
Сообщение: Re: Use windows VMs instead of windows containers on the CI