From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | alvherre(at)2ndquadrant(dot)com, michael(dot)paquier(at)gmail(dot)com, thomas(dot)munro(at)enterprisedb(dot)com |
Cc: | jeff(dot)janes(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Making tab-complete.c easier to maintain |
Date: | 2015-11-17 10:25:24 |
Message-ID: | 20151117.192524.95155716.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20151117(dot)153543(dot)183036803(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> At Mon, 16 Nov 2015 12:16:07 -0300, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote in <20151116151606(dot)GW614468(at)alvherre(dot)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(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20151117(dot)160925(dot)45883793(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Allow-regex-module-to-be-used-outside-server.patch | text/x-patch | 4.3 KB |
0002-Replace-previous-matching-rule-with-regexps-take-2.patch | text/x-patch | 15.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2015-11-17 10:29:48 | Re: Freeze avoidance of very large table. |
Previous Message | Dean Rasheed | 2015-11-17 09:41:42 | Re: Bug in numeric multiplication |