Thank you for looking on this and the comment.
At Mon, 7 Dec 2015 15:00:32 +0900, Michael Paquier <[email protected]>
wrote in <CAB7nPqQ69EPZkOqHAVuZXPxNzb_c2R5hs88tedLYqU9=zu6...@mail.gmail.com>
> On Thu, Nov 26, 2015 at 2:45 PM, Kyotaro HORIGUCHI
> <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers