Re: Rationalizing declarations of src/common/ variables

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Rationalizing declarations of src/common/ variables
Дата
Msg-id CA+TgmoZQzHhTR=QNSpOO+SXBMV+g=bsfPRfjkvmfO5FKvpBe8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rationalizing declarations of src/common/ variables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rationalizing declarations of src/common/ variables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Can I assume relation would not be invalid during from ExecutorRun to ExecutorEnd
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Correct handling of blank/commented lines in PSQL interactive-mode history