Re: Rationalizing declarations of src/common/ variables
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-11-29T14:39:49Z
Lists: pgsql-hackers
On Mon, Nov 29, 2021 at 9:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > What's the value of introducing PGDLLIMPORT_FE? I mean suppose we just > > make PGDLLIMPORT expand to nothing in front-end code. > > Hmm ... fair question. It feels like that risks breaking something, > but offhand I can't see what, as long as we're certain that FRONTEND > is set correctly in every compile. If it isn't, your way might go wrong too, since it depends on FRONTEND being set correctly at least at the point when the PGDLLIMPORT_FE macro is defined. But that is not to say that I think everything is in great shape in this area. In a perfect world, I think the only '#define FRONTEND 1' in the backend would be in postgres_fe.h, but we have it in 5 other places too, 3 of which include a comment saying that it's an "ugly hack". Until somebody cleans that mess up, we have at least three cases to worry about: backend code that includes "postgres.h", front code that includes "postgres-fe.h", and frbontackend code that first does #define FRONTEND 1 and then includes "postgres.h" anyway. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Simplify declaring variables exported from libpgcommon and libpgport.
- e04a8059a74c 15.0 landed