Thomas Munro <thomas.mu...@gmail.com> writes:
> On Thu, Dec 5, 2024 at 10:58 AM Thomas Munro <thomas.mu...@gmail.com> wrote:
>> On Thu, Dec 5, 2024 at 10:55 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Could another way be to read pg_config.h before postgres_ext.h?
>>> I think the current order was intentional, but maybe the
>>> disadvantages outweigh the advantages now.
> Seems good to me. Also there were another couple of contortions due
> to the older ordering, which we could improve I think?
In c.h, I'd put in a very explicit comment in front of pg_config.h.
Also, I don't like making it look like postgres_ext.h is of the
same ilk as the config headers, since it isn't. So maybe like
/*
* These headers must be included before any system headers, because
* on some platforms they affect the behavior of the system headers
* (for example, by defining _FILE_OFFSET_BITS).
*/
#include "pg_config.h"
#include "pg_config_manual.h" /* must be after pg_config.h */
#include "pg_config_os.h" /* must be before any system header files */
/* Pull in fundamental symbols that we also expose to applications */
#include "postgres_ext.h"
/* System header files that should be available everywhere in Postgres */
#include <inttypes.h>
...
The comment for pg_config_os.h is redundant this way, maybe we could
rewrite it as something more useful?
Also, there's probably no reason anymore that postgres_ext.h couldn't
be placed after those fundamental system headers, and that might be
clearer. (I think perhaps the main reason for the existing ordering
was to demonstrate that postgres_ext.h could be included before any
system headers, and that's no longer a consideration.)
I don't especially care for your proposed changes to postgres_ext.h.
That substantially expands the footprint of what gets defined by
pulling that in, and some users might not care for that. (For
example, because they have ordering assumptions similar to what we're
dealing with here.) Now you already snuck the camel's nose under the
tent by including stdint.h there, and maybe these additional headers
wouldn't do any further damage. But I don't see a strong argument to
change long-standing external APIs any more than we absolutely must.
regards, tom lane
