Curated Network Connection-Graph Function-Overload Automation: A Name Is Not a Signature

Writing a script to find and close every database function a specific role can still call is a genuinely sound way to verify an access-control migration actually worked — measuring the real, resulting privilege rather than trusting that the SQL that granted or revoked it did what it was meant to. The precision of that verification depends entirely on how uniquely the script identifies which functions to check. A database function's plain name is a convenient, human-readable identifier — and, in a system that uses function overloading (multiple functions sharing one name, distinguished only by their parameter types, a standard and often deliberately-used database feature), a name alone can refer to more than one actual function. A script built to search by name can correctly close one signature while remaining completely unaware a second, differently-signed function with the identical name still exists, still has its own separate privilege, and was never examined at all.

As part of closing public database access after a batch of security migrations, Centriu Vértice's own team wrote a dedicated verification script specifically to find every database function the anonymous, unauthenticated role could still invoke — a genuinely rigorous step, going beyond re-reading migration SQL to actually measuring the resulting privilege against a real database.

That script identified candidate functions by matching Postgres's own function-name column. In a database that uses function overloading — the same function name serving two or more genuinely different functions, distinguished only by which parameter types each one accepts, a standard and, in this codebase, deliberately-used feature — a name-based match cannot distinguish between them. Two specific overloaded signatures, sharing a name with a sibling overload that HAD already been correctly closed, were invisible to the script for exactly that reason: from the script's perspective, that function name had already been handled.

The two overloads that slipped through were confirmed, by probing the real production database with a calibrated test distinguishing "the object does not exist" from "permission is explicitly denied" from "the function genuinely answered," to still be fully callable using nothing but the public anonymous key. One answers whether two specific network members, identified by their own internal identifiers, are connected to each other — in a curated, application-only professional network, this relationship graph is not an incidental detail; it is close to the core of what the product actually offers a paying member. The second governs access tied to staff-only internal messaging, reachable through a parameter-based calling convention that no actual, legitimate policy anywhere in the product's own code was found to use in that specific overloaded form.

The fix revokes execute privilege from the two specific, exact signatures that remained open — not the function name in general, which would also have closed a DIFFERENT, legitimately-used overload of the connection-checking function that a separate row-level security policy elsewhere in the product depends on to correctly evaluate a member's own visible connections. A row-level security policy expression runs with the privilege of whoever is running the query that triggered it, not the function owner's — removing that overload's own privilege entirely would have broken a legitimate, currently-working feature rather than closing only the actual gap. The fix's own verification required a specific, deliberate first step before doing anything: a check confirming the anonymous role genuinely still had access to the target overloads BEFORE the fix ran, specifically because attempting to revoke a privilege that does not exist produces no error in PostgreSQL — a script that skipped this check could report success on a revoke that changed nothing, having targeted a signature that was never actually open.

Before the fix, anyone holding Centriu Vértice's public anonymous key — present, by design, in the browser bundle of any page the product serves — could call the specific function checking whether two given members were connected, supplying any two real member identifiers, and receive a genuine true-or-false answer about a private professional relationship, with no login and no membership of their own. After the fix, the identical call is rejected outright: the anonymous role holds no execute privilege on that specific function signature, while a legitimately logged-in member's own, correctly-scoped view of their own connections continues to work exactly as designed, through the separate overload the fix deliberately left untouched.

Centriu Vértice's connection-graph and staff-messaging database functions no longer accept the anonymous role's execute privilege on the two specific overloaded signatures a name-only cleanup script had missed, while the product's own legitimate use of a sibling overload — relied on by an existing row-level security policy — continues to work exactly as before, verified by a live measurement against the real production database rather than a reading of the migration SQL alone.

This automation governs the internal database access-control verification methodology behind Centriu Vértice's own curated professional network — it does not change what a logged-in, authorized member can see about their own connections, does not add a customer-facing setting, and is specific to a database that uses function overloading; a system where every function name maps to exactly one signature would not be exposed to this specific class of gap in the first place.

Writing a verification script that identifies functions by name is simpler to write and, in a database with no function overloading at all, is completely sufficient — the risk is specific and easy to overlook in any system that DOES use overloading deliberately elsewhere, because a name-based check can report a clean result while a sibling function sharing that exact name remains entirely unexamined. Matching by a function's full, exact signature — name plus parameter types together — closes that gap directly, at the cost of a script that has to reason about signatures rather than the more convenient, but structurally incomplete, plain name.