Summary
There are legitimate reasons to track (assign an object_id to) an object that is itself a member of some other PostgreSQL extension — unlike an object belonging to object_reference itself, which must never be tracked (see #40). But allowing this implicitly, with no signal that the caller intended it, risks silently tracking an extension-owned object the caller didn't realize was extension-owned.
Proposal
Add an explicit opt-in argument to every public API function that can create a new tracked object (e.g. object__getsert()), defaulting to not allowing it. A caller who actually wants to track an object they know belongs to another extension must explicitly pass something like expect_extension_member => true. Without it, attempting to track such an object should fail loudly rather than silently succeed.
Scope
Deliberately out of scope for the initial OID-repair implementation (#38) — filed separately, per the repo owner's request to keep that work narrowly scoped. Independent of, and orthogonal to, #40's "never track object_reference's own objects" rule, which has no opt-out.
Summary
There are legitimate reasons to track (assign an
object_idto) an object that is itself a member of some other PostgreSQL extension — unlike an object belonging toobject_referenceitself, which must never be tracked (see #40). But allowing this implicitly, with no signal that the caller intended it, risks silently tracking an extension-owned object the caller didn't realize was extension-owned.Proposal
Add an explicit opt-in argument to every public API function that can create a new tracked object (e.g.
object__getsert()), defaulting to not allowing it. A caller who actually wants to track an object they know belongs to another extension must explicitly pass something likeexpect_extension_member => true. Without it, attempting to track such an object should fail loudly rather than silently succeed.Scope
Deliberately out of scope for the initial OID-repair implementation (#38) — filed separately, per the repo owner's request to keep that work narrowly scoped. Independent of, and orthogonal to, #40's "never track
object_reference's own objects" rule, which has no opt-out.