From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE |
Date: | 2018-09-21 20:20:42 |
Message-ID: | 6546.1537561242@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Fri, Sep 21, 2018 at 5:52 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Here's a very quick-and-dirty implementation of this approach. Some very
>> very brief testing seems to indicate it works, although I'm sure not
>> perfectly.
> And here is a quick-and-dirty variadic COMPLETE_WITH(...). Together:
I'm a bit inclined to get rid of the need for PP_NARG() by instead making
the macros add a trailing NULL argument, viz
#define TailMatches(...) \
CheckTailMatchesFor(previous_words_count, previous_words, __VA_ARGS__, NULL)
This'd require (some of) the implementation functions to iterate over
their variadic arguments twice, the first time merely counting how many
there are. But we aren't exactly concerned about max runtime performance
here, and the PP_NARG() thing seems like a crock that could easily blow
out compilation time on some compilers.
If people are OK with that design decision, I'm happy to assemble these
pieces and push it through. I just had to add two more versions of
HeadMatchesN :-( so I'm feeling motivated to make something happen.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-21 20:51:53 | Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE |
Previous Message | Tom Lane | 2018-09-21 20:01:19 | Re: Redundant psql tab-completion for CREATE PUBLICATION |