Re: Small and unaffected typo in pg_logical_slot_get_changes_guts()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Small and unaffected typo in pg_logical_slot_get_changes_guts()
Date: 2022-02-18 01:28:48
Message-ID: Yg72ULTrcb+W2Gtg@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-18 01:36:12 Re: adding 'zstd' as a compression algorithm
Previous Message Michael Paquier 2022-02-18 01:18:51 Re: adding 'zstd' as a compression algorithm