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

From Michael Paquier
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
Msg-id 20200930055025.GA1996@paquier.xyz
Whole thread Raw
In response to Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Keisuke Kuroda
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: Dilip Kumar
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)