Re: Remove no-op pull_var_clause flag - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove no-op pull_var_clause flag
Date
Msg-id 2502876.1769049596@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove no-op pull_var_clause flag  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> On Thu, Jan 22, 2026 at 3:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Alexander Pyhalov <a.pyhalov@postgrespro.ru> writes:
>>> I was a bit surprised, the patch hasn't landed to master. But flag
>>> somehow slipped in (but only as no-op). The attached patch removes
>>> useless flag.

>> Right, done.

> Ugh... I wonder how this happened, and whether this is the only
> instance of private code sneaking into the PostgreSQL codebase.  I'm
> also kind of concerned about the legal risk if this comes from a
> project with a strict license.

Unless there's more here than the one single symbol name, I'm not
worried about legal risk --- it's hard to claim copyright or patent
interests in that much.  In any case, it's hard to see postgrespro.ru
suing the rest of us over their own mistake.

> Should we also remove this code from v18?

I thought about it but desisted.  There's some epsilon-level risk
that somebody already copied the pull_var_clause call with
PVC_INCLUDE_PLACEHOLDERS into their extension.  If so, their code
isn't broken today but would be if we back-patched.  Tiny as that
risk is, the benefit of removing the symbol from v18 isn't larger.

Also, while I believe our newly-minted libabigail ABI-checking
infrastructure isn't smart enough to complain about removal of a
macro symbol, it's possible that downstream packaging systems
would notice that and flag it as an inappropriate API change.
Again, the bureaucracy involved in dealing with such a complaint
seems to outweigh the benefit.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Flush some statistics within running transactions
Next
From: Neil Chen
Date:
Subject: Re: [PATCH] Align verify_heapam.c error message offset with test expectations