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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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