Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
От | Tom Lane |
---|---|
Тема | Re: Discontent with development process (was:Re: pgaccess - the discussion is over) |
Дата | |
Msg-id | 25563.1021384367@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Discontent with development process (was:Re: pgaccess (Hannu Krosing <hannu@tm.ee>) |
Список | 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 по дате отправления: