Hi! I've been testing the PostgreSQL extension and found two issues that crash the backend process (killing the client connection):
1. ruvector_list_agents() / ruvector_find_agents_by_capability()
The SQL in ruvector--2.0.0.sql declares RETURNS SETOF jsonb, but the Rust functions return a TableIterator with named composite columns. PostgreSQL expects a single JSONB datum per row and crashes on the mismatch.
2. ruvector_sparql_json() with invalid input
An invalid SPARQL query causes a Rust panic that bypasses pgrx's error handler. This is partly because the workspace Cargo.toml sets panic = "abort" in the release profile, which makes catch_unwind a no-op and also prevents pgrx from converting Result::Err into PostgreSQL errors (pgrx relies on unwinding).
I have a working fix for both if you'd like a PR. Happy to adjust it to match your preferred style.
Hi! I've been testing the PostgreSQL extension and found two issues that crash the backend process (killing the client connection):
1.
ruvector_list_agents()/ruvector_find_agents_by_capability()The SQL in
ruvector--2.0.0.sqldeclaresRETURNS SETOF jsonb, but the Rust functions return aTableIteratorwith named composite columns. PostgreSQL expects a single JSONB datum per row and crashes on the mismatch.2.
ruvector_sparql_json()with invalid inputAn invalid SPARQL query causes a Rust panic that bypasses pgrx's error handler. This is partly because the workspace
Cargo.tomlsetspanic = "abort"in the release profile, which makescatch_unwinda no-op and also prevents pgrx from convertingResult::Errinto PostgreSQL errors (pgrx relies on unwinding).I have a working fix for both if you'd like a PR. Happy to adjust it to match your preferred style.