Re: Making tab-complete.c easier to maintain

Thank you for looking on this and the comment.

At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqQ69EPZkOqHAVuZXPxNzb_c2R5hs88tedLYqU9=Zu6xOw(at)mail(dot)gmail(dot)com>
> On Thu, Nov 26, 2015 at 2:45 PM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > What do you think about this solution?
>
> <please do not top-post, it breaks the logic of the thread>

I believe I haven't ripped off any in CC: list or In-Reply-To and
References in the previous post. (I read "top-post" as a post
without these headers.) Could you let me know how the message
was broken?

> This patch fails to compile on OSX:
> Undefined symbols for architecture x86_64:
> "_ExceptionalCondition", referenced from:
> _pg_regexec in regexec.o
> _cfind in regexec.o
> _find in regexec.o
> _newdfa in regexec.o
> _cfindloop in regexec.o
> _shortest in regexec.o
> _cdissect in regexec.o
> ...
> So, to begin with, this may be better if replugged as a standalone
> library, aka moving the regexp code into src/common for example or
> similar.

I agree to that. I'll consider doing so. (But my middle finger
tip injury makes me further slower than usual..)

> Also, per the comments on top of rcancelrequested,
> rstacktoodeep and rcancelrequested, returning unconditionally 0 is not
> a good idea for -DFRONTEND. Callbacks should be defined and made
> available for callers.

cancel_pressed is usable for the purpose and I'll add
cancel_callback feeature to separate it from both frontend and
backend.

> - {"EVENT TRIGGER", NULL, NULL},
> + {"EVENT TRIGGER", Query_for_list_of_event_triggers, NULL},
> {"EXTENSION", Query_for_list_of_extensions},
> - {"FOREIGN DATA WRAPPER", NULL, NULL},
> + {"FOREIGN DATA WRAPPER", Query_for_list_of_fdws, NULL},
> {"FOREIGN TABLE", NULL, NULL},
> {"FUNCTION", NULL, &Query_for_list_of_functions},
> {"GROUP", Query_for_list_of_roles},
> {"LANGUAGE", Query_for_list_of_languages},
> {"INDEX", NULL, &Query_for_list_of_indexes},
> - {"MATERIALIZED VIEW", NULL, NULL},
> + {"MATERIALIZED VIEW", NULL, &Query_for_list_of_matviews},
> This has value as a separate patch.

I carelessly merged it in the fourth (Merge mergable...)
patch. I'll separate it.

> The patch has many whitespaces, and unrelated diffs.

Mmm, thanks for pointing it out. I haven't see such lines differ
only in whitespaces or found unrelated diffs so far but I'll
check it out.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center