Re: #include oddity in v7.0b3

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> > What do you think ? Was this change intentional ?
>
> It was. Someone else complained that the other way didn't work for them.
> At least from the point of libpq, I think they were right.

I don't understand why. Could you explain ?

> Certainly hardcoding a full path into application source code is a
> completely unportable way to do things...

Obviously, we're smarter than that. I had simplified the example to
point at the problem clearly. Since we've already encountered different
possible locations for postgresql headers, we actually detect their location
at configure time, #define a macro containing the path, and use something like
#include <THE_PATH/the_file.h> (this is yet simplified, but that's the idea).

But that's not the point. When an application has to include a single
header from a library, and when this application knows where to find it, it
should be able to include it directly without special cpp cooking. That's why
headers installed in the same place should use "" and not <> to #include each
others.

The only valid reason for this change I can see is that libpq-fe.h and
postgres_ext.h could happen to be installed at different locations. Can this
be the case ?

--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier(at)lrde(dot)epita(dot)fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99