Re: PG12, PGXS and linking pgfeutils

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PG12, PGXS and linking pgfeutils
Дата
Msg-id 26438.1557422453@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PG12, PGXS and linking pgfeutils  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PG12, PGXS and linking pgfeutils
Список pgsql-hackers
I wrote:
> Ian Barwick <ian.barwick@2ndquadrant.com> writes:
>> Commit cc8d4151 [*] introduced a dependency between some functions in
>> libpgcommon and libpgfeutils,

> This seems rather seriously broken.  I do not think the answer is to
> create a global dependency on libpgfeutils.

Or, to be clearer: fe_utils has had dependencies on libpgcommon since
its inception.  What we are seeing here is that libpgcommon has now
grown some dependencies on libpgfeutils.  That can't be allowed to
stand.  We'd be better off giving up on the separation between those
libraries than having circular dependencies between them.

I'm not especially on board with the idea of moving FE-specific error
handling code into libpgcommon, as that breaks the concept that
src/common/ is broadly for code that can work in either frontend or
backend contexts.  However, we already have a few violations of that
rule: common/Makefile already has

# A few files are currently only built for frontend, not server
OBJS_FRONTEND = $(OBJS_COMMON) fe_memutils.o file_utils.o restricted_token.o

So maybe the answer is to move these logging support functions into
src/common, in a file that's only built for frontend.

            regards, tom lane



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: PG12, PGXS and linking pgfeutils