Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)
Date: 2020-09-30 05:50:25
Message-ID: 20200930055025.GA1996@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Tue, Sep 29, 2020 at 09:29:18AM -0400, Tom Lane wrote:
> Hm, it doesn't seem like "OBJS_PGCOMMON" conveys much. I think
> OBJS_FRONTEND ought to be the set of files built for frontend
> application use (i.e., libpgcommon.a), so we need a new name
> for what will go into libpgcommon_shlib.a. Maybe OBJS_SHLIB,
> or to be even more explicit, OBJS_FRONTEND_SHLIB.

OBJS_SHLIB is already used to list the _shlib.o objects compiled with
libpgcommon_shlib.a, which is why I switched OBJS_FRONTEND to
OBJS_PGCOMMON, and an object cannot reference itself so we either need
two variables for the shlib list, or we could just do something like
that:
OBJS_FRONTEND = \
$(OBJS_COMMON) \
fe_memutils.o \
restricted_token.o \
sprompt.o
OBJS_SHLIB = $(OBJS_FRONTEND:%.o=%_shlib.o)
OBJS_FRONTEND += logging.o

However I would prefer the style of the attached.

> As for the comment, maybe "logging.c is excluded from OBJS_SHLIB
> as a matter of policy, because it is not appropriate for general
> purpose libraries such as libpq to report errors directly."

WFM. Thanks!
--
Michael

Attachment Content-Type Size
common-shlib-split-v2.patch text/x-diff 998 bytes

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2020-09-30 05:59:58 pgsql: Fix XML id to match GUC name
Previous Message David Rowley 2020-09-30 00:05:42 pgsql: Doc: Improve clarity on partitioned table limitations

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-09-30 05:58:44 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message Keisuke Kuroda 2020-09-30 05:39:03 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables