Re: PG12, PGXS and linking pgfeutils - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PG12, PGXS and linking pgfeutils
Date
Msg-id 26438.1557422453@sss.pgh.pa.us
Whole thread Raw
In response to Re: PG12, PGXS and linking pgfeutils  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PG12, PGXS and linking pgfeutils  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Alvaro Herrera
Date:
Subject: Re: PG12, PGXS and linking pgfeutils