Remove no-op pull_var_clause flag

Alexander Pyhalov <a.pyhalov@postgrespro.ru> writes:

While merging PostgreSQL to our (Shardman) fork, I've noticed that it
uses the same pull_var_clause() flag as we do (coming from
/messages/by-id/CAFjFpRc8ZoDm0+zhx+MckwGyEqkOzWcpVqbvjaxwdGarZSNrmA@mail.gmail.com).
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.

regards, tom lane

On Thu, Jan 22, 2026 at 3:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alexander Pyhalov <a.pyhalov@postgrespro.ru> writes:

While merging PostgreSQL to our (Shardman) fork, I've noticed that it
uses the same pull_var_clause() flag as we do (coming from
/messages/by-id/CAFjFpRc8ZoDm0+zhx+MckwGyEqkOzWcpVqbvjaxwdGarZSNrmA@mail.gmail.com).
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.

Should we also remove this code from v18?

- Richard

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