Re: Making tab-complete.c easier to maintain

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Making tab-complete.c easier to maintain
Дата
Msg-id 20151208.183110.229901672.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Making tab-complete.c easier to maintain  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Making tab-complete.c easier to maintain  (Michael Paquier <michael.paquier@gmail.com>)
Re: Making tab-complete.c easier to maintain  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Thank you for looking on this and the comment.

At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqQ69EPZkOqHAVuZXPxNzb_c2R5hs88tedLYqU9=Zu6xOw@mail.gmail.com>
> On Thu, Nov 26, 2015 at 2:45 PM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.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





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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Some bugs in psql_complete of psql
Следующее
От: Jeremy Harris
Дата:
Сообщение: Re: [PATCH] Equivalence Class Filters