feat: add schema comments and materialized view support

[stephanhaeuslschmid]

Summary

• Schema comments: list_objects and get_object_details now include PostgreSQL COMMENT ON metadata via obj_description() and col_description() from pg_catalog
• Materialized views: New object_type='materialized_view' for both tools, querying pg_class (since materialized views are not in information_schema)

Motivation

LLMs using this MCP server to explore databases cannot currently see schema documentation stored as COMMENT ON TABLE/VIEW/COLUMN statements — the standard PostgreSQL mechanism for documenting columns (units, enums, business logic). This makes it much harder for LLMs to correctly interpret data.

Similarly, materialized views (commonly used for analytics/reporting layers) are invisible because information_schema.tables does not include them.

Changes

list_objects:

• Tables and views now include obj_description() as comment field
• New object_type='materialized_view' queries pg_class WHERE relkind = 'm' with comments

get_object_details:

• Column results now include col_description() as comment field
• Object-level comment added to basic section via obj_description()
• For materialized views, columns are queried from pg_attribute (not information_schema.columns)

Example

COMMENT ON TABLE raw.orders IS 'Customer orders. One row per order. Currency: EUR.';
COMMENT ON COLUMN raw.orders.amount IS 'Order total in EUR cents. Divide by 100 for EUR.';

These comments now appear in list_objects and get_object_details responses, giving LLMs the context they need to write correct queries.

Closes #71

[jssmith]

Review — concise

Verdict: Approve with comments. Solid feature addition — materialized view support and schema comments are both useful.

Strengths

• Materialized view support in list_objects and get_object_details. Uses pg_class/pg_attribute for matview columns (correct — they're not in information_schema.columns).
• Schema comments via obj_description() and col_description() added to both listing and detail views.
• obj_description, col_description, shobj_description added to SafeSqlDriver allowlist. Correct.
• Tool descriptions improved with better LLM-guidance language.

Issues to address

1. quote_ident in (quote_ident(...) || '.' || quote_ident(...))::regclass may fail on non-existent relations (non-blocking)
In list_objects, the obj_description call casts the schema-qualified name to regclass. If a table is dropped between the information_schema.tables query and the obj_description evaluation (unlikely but possible in concurrent environments), this will raise an error. Consider using pg_class.oid directly via a JOIN instead of the ::regclass cast.

2. Materialized view table_type value inconsistency (non-blocking)
list_objects returns "MATERIALIZED VIEW" for matviews but information_schema.tables returns "BASE TABLE" or "VIEW". The list_objects filter maps object_type to table_type values — verify the mapping for materialized_view is handled in the table_type parameter value. Looking at the code, the matview branch is separate (uses pg_class directly), which is correct, but the returned "type": "MATERIALIZED VIEW" doesn't match information_schema conventions. Document or standardize.

3. No tests for materialized view queries (non-blocking)
The diff adds no tests. Consider adding unit tests that mock the SQL driver and verify the correct queries are executed for object_type="materialized_view" in both list_objects and get_object_details.

This review was created by an AI agent (OpenHands) on behalf of @jssmith.