Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts
Date
Msg-id CA+TgmoZLs5gajFDi0rD6aoL4=4uRRDM=c09UEUyPjaWThxwipw@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: PATCH: pgbench - option to build using ppoll() for largerconnection counts  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Wed, Nov 29, 2017 at 8:10 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> My point is consistent with my other advice which is to hide the stuff in
> functions with identical (or compatible) signatures, so that the only place
> where it would differ would be in the functions, where greping would work.
>
>  #ifdef USE_POLL
>   // pool specific stuff
>   #define SOME_TYPE v1_type (or typedef)
>   void do_stuff(v1_type * stuff) { ... }
>   ...
>  #else /* default to SELECT */
>   // select specific stuff
>   #define SOME_TYPE v2_type (idem)
>   void do_stuff(v2_type * stuff) { ... }
>   ...
>  #endif
>
> Then later the code is not specific to poll or select, eg:
>
>  SOME_TYPE mask;
>  do_stuff(mask);
>  do_other_stuff(...);
>  if (is_ready(mask, ...)) { ... }

Yeah, that sort of style would be OK with me.  But I wouldn't like:

struct blah {
#ifdef FOO   int doohicky;
#else   char *doohicky;
};

...because now any place in the code where you see "doohicky" you
don't immediately know whether it's an int or a char *

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] postgres_fdw super user checks
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] static assertions in C++