[GH-ISSUE #6211] [Design] Add read-only PostgreSQL inspection #3781

New issue

Open

opened 2026-10-31 00:44:00 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:44:00 +00:00

Owner

Originally created by @XuZw-w on GitHub (Oct 22, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6211

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Should REA add a PostgreSQL inspection provider for an explicitly selected database, returning schema inventory and selected table/column samples inline and as queryable Evidence? What connection, network, authorization, and result boundaries should apply?

Context and evidence

REA currently documents inspect_sqlite_database for selected local SQLite snapshots and optional table samples (docs/sqlite-databases.md). This does not support PostgreSQL servers. I want to use REA to inspect an existing PostgreSQL database and see selected results directly in the investigation conversation.

Assumption: PostgreSQL is an analysis target, not a persistence backend for REA's own Evidence. A useful first workflow would show a compact schema inventory and, only when selected, a bounded sample from specified tables and columns. The agent should render that sample in a readable table in chat while preserving structured Evidence and a complete JSON result for the selected scope.

Unknowns for maintainer guidance include connection and credential handling, whether loopback-only should be the initial boundary, supported PostgreSQL objects and types, and query/response/time limits. No PostgreSQL provider runtime verification has been performed for this proposal. Searches for PostgreSQL inspection issues and pull requests found no related proposal.

Expected interaction with targets

Contact network services

Boundary details (optional)

Proposal for discussion only: connect only to a caller-selected PostgreSQL endpoint/database; network service interaction is required, and remote-host support should be explicitly reviewed. Do not accept arbitrary SQL or expose DDL/DML. Prefer fixed catalog queries plus parameterized reads from caller-selected ordinary tables and columns under a least-privilege read-only database role/transaction. Keep credentials out of MCP arguments, Evidence, and logs. Do not access unselected columns; row values may be sensitive, so require explicit selection and bounded samples. Report coverage and truncation. Views, custom types/functions, large objects, and extension-backed fields need explicit semantics.

Options and tradeoffs

Keep PostgreSQL as a separate target inspector that reuses REA's database-inspection and Evidence conventions, with both MCP and CLI surfaces. A dedicated PostgreSQL MCP connector could be an alternative if REA should not own connection lifecycle. Using PostgreSQL to store REA's own Evidence is a separate proposal.

Verification available so far

Idea only; I need help defining checks

Success criteria and open questions

Maintainers first decide the provider's scope and target-interaction boundaries. After approval and implementation, users should see selected schema and row samples as readable tables in the REA conversation, with structured Evidence and CLI JSON. Verify against a self-owned disposable PostgreSQL fixture and least-privilege read-only role through real CLI and MCP workflows, including authentication failures, network refusal, timeouts, credential redaction, row/byte bounds, and resource cleanup.

References

https://github.com/morluto/rea/blob/main/docs/sqlite-databases.md
https://github.com/morluto/rea/blob/main/docs/tool-design.md
https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope

Originally created by @XuZw-w on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6211 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should REA add a PostgreSQL inspection provider for an explicitly selected database, returning schema inventory and selected table/column samples inline and as queryable Evidence? What connection, network, authorization, and result boundaries should apply? ### Context and evidence REA currently documents `inspect_sqlite_database` for selected local SQLite snapshots and optional table samples ([docs/sqlite-databases.md](https://github.com/morluto/rea/blob/main/docs/sqlite-databases.md)). This does not support PostgreSQL servers. I want to use REA to inspect an existing PostgreSQL database and see selected results directly in the investigation conversation. Assumption: PostgreSQL is an analysis target, not a persistence backend for REA's own Evidence. A useful first workflow would show a compact schema inventory and, only when selected, a bounded sample from specified tables and columns. The agent should render that sample in a readable table in chat while preserving structured Evidence and a complete JSON result for the selected scope. Unknowns for maintainer guidance include connection and credential handling, whether loopback-only should be the initial boundary, supported PostgreSQL objects and types, and query/response/time limits. No PostgreSQL provider runtime verification has been performed for this proposal. Searches for PostgreSQL inspection issues and pull requests found no related proposal. ### Expected interaction with targets Contact network services ### Boundary details (optional) Proposal for discussion only: connect only to a caller-selected PostgreSQL endpoint/database; network service interaction is required, and remote-host support should be explicitly reviewed. Do not accept arbitrary SQL or expose DDL/DML. Prefer fixed catalog queries plus parameterized reads from caller-selected ordinary tables and columns under a least-privilege read-only database role/transaction. Keep credentials out of MCP arguments, Evidence, and logs. Do not access unselected columns; row values may be sensitive, so require explicit selection and bounded samples. Report coverage and truncation. Views, custom types/functions, large objects, and extension-backed fields need explicit semantics. ### Options and tradeoffs Keep PostgreSQL as a separate target inspector that reuses REA's database-inspection and Evidence conventions, with both MCP and CLI surfaces. A dedicated PostgreSQL MCP connector could be an alternative if REA should not own connection lifecycle. Using PostgreSQL to store REA's own Evidence is a separate proposal. ### Verification available so far Idea only; I need help defining checks ### Success criteria and open questions Maintainers first decide the provider's scope and target-interaction boundaries. After approval and implementation, users should see selected schema and row samples as readable tables in the REA conversation, with structured Evidence and CLI JSON. Verify against a self-owned disposable PostgreSQL fixture and least-privilege read-only role through real CLI and MCP workflows, including authentication failures, network refusal, timeouts, credential redaction, row/byte bounds, and resource cleanup. ### References https://github.com/morluto/rea/blob/main/docs/sqlite-databases.md https://github.com/morluto/rea/blob/main/docs/tool-design.md https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:44:00 +00:00

bsakaguchi commented

2026-10-31 00:44:01 +00:00

Author

Owner

@tiggachris commented on GitHub (Oct 25, 2026):

I'll take this one.

@tiggachris commented on GitHub (Oct 25, 2026): I'll take this one.