Re: Small and unaffected typo in pg_logical_slot_get_changes_guts() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Small and unaffected typo in pg_logical_slot_get_changes_guts()
Date
Msg-id Yg72ULTrcb+W2Gtg@paquier.xyz
Whole thread Raw
In response to Re: Small and unaffected typo in pg_logical_slot_get_changes_guts()  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
List pgsql-hackers
On Thu, Feb 17, 2022 at 11:33:55AM +0000, Dagfinn Ilmari Mannsåker wrote:
> Would it be possible to make that macro only defined when building
> extensions, but not when building Postgres itself?  For example, Perl
> has a PERL_CORE macro that's only defined when building Perl itself, but
> not when building CPAN modules, and backwards-compatibility macros and
> functions are guarded by `#ifndef PERL_CORE`.

That could be interesting in the long term, as compatibility macros
have accumulated over the years and there are from time to time
patches that are merged that make use of things they should not.

With the build we have now, I am not completely sure how you would do
the split though.  Extensions are one thing, and we could set a flag
as part of USE_PGXS.  There is also the popular case where extensions
are copied into the tree where we would not have USE_PGXS for them.
That would cause compilation failures.  Another limit that could be
defined is to limit the removal of the compatibility macros for
src/backend/ and src/bin/, leaving any in-core modules out of the
picture.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: adding 'zstd' as a compression algorithm
Next
From: Andres Freund
Date:
Subject: Re: adding 'zstd' as a compression algorithm