Re: Discontent with development process (was:Re: pgaccess - the discussion is over) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
Date
Msg-id 25563.1021384367@sss.pgh.pa.us
Whole thread Raw
In response to Re: Discontent with development process (was:Re: pgaccess  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> What would your opinion be of some hack with macros, like 

> #if (Win32 or THREADED)
> #define GLOBAL_ pg_globals.
> #else
> #define GLOBAL_
> #endif

> and then use global variables as

> GLOBAL_globvar

> At least in my opinion that would increase both readability and
> maintainability.

From a code readability viewpoint this is not at all better than just
moving everything to pg_globals.  You're only spelling "pg_globals."
a little differently.  And it introduces twin possibilities for error:
omitting GLOBAL_ (if you're a Unix developer) or writing
pg_globals. explicitly (if you're a Win32 guy).  I suppose these errors
would be caught as soon as someone tried to compile on the other
platform, but it still seems like a mess with little redeeming value.

I think there had been some talk of

#if Win32
#define myvar  pg_globals.f_myvar
#else
static int myvar;
#endif

which seems a more effective use of macros --- it would at least allow
the code to be written without explicit awareness of the special status
of the variable.  Still seems like a maintenance nightmare though.

The real problem with airily saying "we'll just move that variable to
pg_globals" is that it falls down the instant that you consider
non-scalar variables.  What if it's a pointer to a palloc'd structure?
Sure we can get around this, but not transparently.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: strange explain
Next
From: Jan Wieck
Date:
Subject: Re: Discontent with development process (was:Re: pgaccess