Re: PG12, PGXS and linking pgfeutils

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG12, PGXS and linking pgfeutils
Date: 2019-05-09 17:20:53
Message-ID: 26438.1557422453@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-05-09 17:39:11 Re: PG12, PGXS and linking pgfeutils
Previous Message Bruce Momjian 2019-05-09 16:44:20 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)