From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: assorted code cleanup
Date: Tue, 5 Sep 2017 15:12:41 -0400
Message-ID: <f52c16db-14ed-757d-4b48-7ef360b1631d@2ndquadrant.com> (raw)
In-Reply-To: <CAB7nPqQHnB_qS41P+Vsi=CrE3L2rjp37F8WX-dJceLzEWO+rvw@mail.gmail.com>
References: <2beab0ef-69f9-dab3-cacd-8fdf417bca96@2ndquadrant.com>
<CAB7nPqQHnB_qS41P+Vsi=CrE3L2rjp37F8WX-dJceLzEWO+rvw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, michael.paquier@gmail.com
Subject: Re: assorted code cleanup
In-Reply-To: <f52c16db-14ed-757d-4b48-7ef360b1631d@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox