Re: Making tab-complete.c easier to maintain
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Making tab-complete.c easier to maintain |
Дата | |
Msg-id | 20151117.192524.95155716.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Making tab-complete.c easier to maintain (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Making tab-complete.c easier to maintain
|
Список | pgsql-hackers |
Hello, I tried to implement the mini-language, which is a simplified reglar expression for this specific use. As a ultra-POC, the attached patch has very ad-hoc preprocess function and does on-the-fly preprocessing, compilation then execution of regular expression. And it is applied to only the first ten or so matchings in psql_completion(). The first attachment is the same with that of previous patchset. Every matching line looks like the following, > else if (RM("ALTER {AGGREGATE|FUNCTION} [#id](..")) > COMPLETE_WITH_FUNCTION_ARG(CAPTURE(1)); As a temporary desin, "{}" means grouping, "|" means alternatives, "[]" means capture and '#id' means any identifier. The largest problem of this would be its computation cost:( This in turn might be too slow if about three hundred matches run... I see no straight-forward way to preprocess these strings.. A possible solution would be extracting these strings then auto-generate a c-srouce to preprocess them. And when running, RM() retrieves the compiled regular expression using the string as the key. At Tue, 17 Nov 2015 15:35:43 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20151117.153543.183036803.horiguchi.kyotaro@lab.ntt.co.jp> > At Mon, 16 Nov 2015 12:16:07 -0300, Alvaro Herrera <alvherre@2ndquadrant.com> wrote in <20151116151606.GW614468@alvherre.pgsql> > > I don't think this is an improvement. It seems to me that a lot more > > work is required to maintain these regular expressions, which while > > straightforward are not entirely trivial (harder to read). > > > > If we could come up with a reasonable format that is pre-processed to a > > regexp, that might be better. I think Thomas' proposed patch is closer > > to that than Horiguchi-san's. > > I aimed that matching mechanism can handle optional elements in > syntexes more robustly. But as all you are saying, bare regular > expression is too complex here. At Tue, 17 Nov 2015 16:09:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20151117.160925.45883793.horiguchi.kyotaro@lab.ntt.co.jp> > if (Match("^,ALTER,TABLE,\id,$") || > Match("^,ALTER,TABLE,IF,EXISTS,\id,$"))... > > Interpreting this kind of mini-language into regular expressions > could be doable.. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: