On 8/21/17 01:11, Michael Paquier wrote: >> - Drop excessive dereferencing of function pointers > > - (*next_ProcessUtility_hook) (pstmt, queryString, > + next_ProcessUtility_hook(pstmt, queryString, > context, params, queryEnv, > dest, completionTag); > But this... Personally I like the current grammar which allows one to > make the difference between a function call with something declared > locally and something that may be going to a custom code path. So I > think that you had better not update the system hooks that external > modules can use via shared_preload_libraries.
Do you mean specifically the hook variables, or any function pointers? I can see your point in the above case, but for example here - if ((*tinfo->f_lt) (o.upper, c.upper, flinfo)) + if (tinfo->f_lt(o.upper, c.upper, flinfo)) I think there is no loss of clarity and the extra punctuation makes it more complicated to read. >> - Remove unnecessary parentheses in return statements > > So you would still keep parenthesis like here for simple expressions: > contrib/bloom/blutils.c: return (x - 1); > No objections. > > Here are some more: > contrib/intarray/_int_bool.c: return (calcnot) ? > contrib/ltree/ltxtquery_op.c: return (calcnot) ? > > And there are many "(0)" "S_ANYTHING" in src/interfaces/ecpg/test/ and > src/interfaces/ecpg/preproc/. Thanks, I included these. >> - Remove our own definition of NULL > > Fine. c.h uses once NULL before enforcing its definition. Actually, that would have worked fine, because the earlier use is a macro definition, so NULL would not have been needed until it is used. >> - fuzzystrmatch: Remove dead code > > Those are remnants of a323ede, which missed to removed everything. Good reference, makes sense. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
