Skip to content

Catalog JOIN routing is bypassed whenever the query also calls a system function #96

Description

@erans

Found during the final review of #87.

src/catalog/query_interceptor.rs branches on whether the query mentions pg_table_is_visible, pg_get_constraintdef, format_type, or pg_get_expr before it reaches the SQLite-backed JOIN routing block, which lives in the else arm.

So this shape:

SELECT c.relname, pg_get_constraintdef(con.oid)
FROM pg_class c JOIN pg_constraint con ON con.conrelid = c.oid

never reaches the routing added in #87. It falls to the per-table dispatch loop, where check_table_factor hands it to PgConstraintHandler with the join predicate unevaluated — WhereEvaluator strips the qualified c.oid to a bare oid and looks it up in pg_constraint's row map.

This is the shape psql and most ORMs emit, so the JOIN fix from #87 is narrower in practice than it appears. \dt is unaffected: it survives because pg_class, pg_namespace, and pg_am all fall through to SQLite from the per-table dispatch.

Not a regression — this is the pre-existing behavior, not something #87 broke. But it is the gap that keeps cross-catalog joins from working generally.

Likely fix: move the SQLite-backed-join check ahead of the system-function branch, or make the system-function branch fall through when every table in the query is SQLite-backed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions