>As for -Wundef, it seems rather impractical to turn that on anyway given >that it produces numerous other warnings --- a quick check in HEAD shows
It looks like my point was missed. I'm talking about compiling user code that interfaces with Postgres. I'm specifically talking about server extensions, so it _is_ sort of part of Postgres and some restrictions make sense. But it's compiled outside of the Postgres build, and that makes a big difference. Often, the point of a C-language extension is to bridge between Postgres and some other world, so Postgres can't completely command the compilation (or runtime) environment -- the extension has to meet the requirements of the other world as well. After I added an #ifdef, none of my server extensions encountered an undefined macro warning, so it does help. Incidentally, for those who have never used -Wundef: It's extremely productive. We've all lost way too much time on bugs that happen because in the tangle header files, ifdefs, and source code updates, we forget to define a macro. That's why all of my code is designed to use #if instead of #ifdef and compile with -Wundef -Werror. I find it so valuable that I even maintain workarounds and local patches of other people's interface header files (e.g. Postgres c.h) to allow me to use it. Of course, it would be better still if Postgres came to me already compatible with this style of development. >I can't get terribly excited about that. The thing is, you don't have to get terribly excited. Just slightly interested. Because it just takes two lines of code with zero chance of messing up anything to provide something with a practical use that makes logical sense as well. -- Bryan Henderson San Jose, California -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
