Re: Patch to include c.h

On Sun, Sep 16, 2012 at 11:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
> > I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
> > directly or indirectly.
>
> In general, all include files in Postgres assume that you've included
> postgres.h or postgres_fe.h (as appropriate) first;

Thankfully, this IDE provides for me to specify preprocessor directives
that are processed before parsing any source files, so it was easy for me
to #include "c.h" in every file.

So, that solved the problem for me, but other IDEs may not be so flexible.

I understand that I am supposed to include postgres.h in backend files, and
postgres_fe.h in frontend files, like those of psql, pg_dump, ecpg, etc.,
but I didn't bother with that for now. If I proceed with this IDE, then I
think it'll make sense to have a project per client program, so that I can
include postgres_fe.h for those projects, and postgres.h for the main
backend project.

and practically
> all of them have far more dependencies on that than you mention here.
> If we were to decorate them with explicit inclusions such as you propose,
> we would accomplish little except to bloat the sources and slow down
> compilation.
>

True, it would affect the compilation times, but I think if one is using
ccache, then they would be sheilded from this on second and subsequent runs.

>
> The general rule about that is "thou shalt have no other gods before
> c.h" --- that is, it is *necessary* that c.h be included before anything
> else, in *every* Postgres file. Otherwise you can run into
> platform-specific problems. An example I remember is individual files
> having different ideas of whether 64-bit or 32-bit filesystem APIs are
> in use, as a consequence of <stdio.h> being read before pg_config_os.h
> has defined symbols controlling that. Needless to say, this doesn't
> work well at runtime. You can find actual examples of that sort of
> thing in the archives from years ago, before we began to enforce the
> rule rigidly.
>

I'm glad that we have this rule in place.

Best regards,
--
Gurjeet Singh

http://gurjeet.singh.im/