fix(postgres): read EXPLAIN JSON output as json column

[debba]

What

Fixes the "Explain Plan" feature for Postgres, which always failed with error deserializing column 0 (#276).

Why it broke

EXPLAIN (FORMAT JSON) ... returns the plan in a single column, and on Postgres that column is typed as json (OID 114), not text. The code read it straight into a String:

let plan_json_str: String = rows[0].try_get(0)...;

tokio-postgres refuses to deserialize a json column into a String, so the call errored out before the plan was ever parsed. This is server-side behaviour that's been stable since the FORMAT option landed in PG 9.0, so the feature never worked on any Postgres version — matching the report against PG 16 and 18.

Fix

Read the column as a serde_json::Value (the with-serde_json-1 feature is already enabled) and re-serialize it for the existing parser. Postgres-compatible engines that hand the plan back as a plain text column are covered by a String fallback.

Testing

• cargo check passes.
• Verified Explain Plan now renders against Postgres locally, with and without Analyze.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Incremental Review (commit b87b318)

The previous nit about discarding the original json_err in the fallback branch has been addressed — the error is now captured and logged via log::debug! before returning the text-read failure. No new issues introduced.

Files Reviewed (1 file)

• src-tauri/src/drivers/postgres/explain.rs - No new issues. Previous nit resolved.

---

_{Reviewed by kimi-k2.6 · 101,317 tokens}

[NewtTheWolf]

@debba overall this looks good to me 👍 — correct root cause (EXPLAIN (FORMAT JSON) on real PostgreSQL returns a json column, OID 114, not text; I verified this locally against PG 16 with \gdesc → QUERY PLAN | json). The fix is minimal, the fallback for text-returning PG-compatible engines is a nice touch, and the comment explains the why well. cargo test explain is green and the Explain Plan now renders end-to-end.

Two optional, non-blocking nits inline — points 1 and 2 below. Happy to approve either way.

[NewtTheWolf]

Nit (non-blocking): this is a triple round-trip — PG sends JSON text → tokio-postgres parses into serde_json::Value → .to_string() re-serializes → parse_postgres_json parses it again. Totally fine for small EXPLAIN output, just flagging in case parse_postgres_json could grow a &serde_json::Value entry point to skip the re-parse. Not worth it unless it's trivial.

[NewtTheWolf]

Test