Repository navigation
feat(postgres): pin subqueries, with queries and views by their keys - #105
Conversation
|
No configured credential can serve this run. Your Claude Pro/Max subscription has hit its usage limit, which resets at 2026-10-26 08:00 UTC. Re-trigger after it resets, or add an API key for this provider, which Pullfrog falls back to automatically. The providers' responses
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
964ebad to
f62d796
Compare
|
No configured credential can serve this run. Your Claude Pro/Max subscription has hit its usage limit, which resets at 2026-10-26 08:00 UTC. Re-trigger after it resets, or add an API key for this provider, which Pullfrog falls back to automatically. The providers' responses
|
A view is pinned by a key its defining statement keeps, read with the keys of the tables it reads. An oracle case covers subqueries, WITH queries and views.
f62d796 to
6133e41
Compare
|
No configured credential can serve this run. Your Claude Pro/Max subscription has hit its usage limit, which resets at 2026-10-26 08:00 UTC. Re-trigger after it resets, or add an API key for this provider, which Pullfrog falls back to automatically. The providers' responses
|
A host that runs the row-count proof itself asks catalog() for the relations a statement reads. Views among them came with no defining statement and none of the keys of the tables they read, so a read by key through a view was never pinned, as an analysis pins it since #105.
* fix(postgres): give a host's row-count catalog its views' keys A host that runs the row-count proof itself asks catalog() for the relations a statement reads. Views among them came with no defining statement and none of the keys of the tables they read, so a read by key through a view was never pinned, as an analysis pins it since #105. * fix(postgres): know every view a statement reads before settling viewed dropped each prefetch it issued, and which list a relation was asked in turned on how many views were known yet, so a round could settle with a view over a view still unread: a read by key through it went unpinned. It now answers only once every prefetch is answered.
A subquery, a WITH query or a view is now pinned to one row by a unique key of its rows, as a table is by its index.
select * from (select id, title from posts) s where s.id = :idwasmanyand is nowmaybeOne, and so are the WITH and view forms.The rule
A set of a subquery's output columns is a key of its rows when either:
The outer WHERE and ON equalities then pin the subquery by that key under the same checks a table's key gets: a value or a pinned item's column, nothing volatile, no COLLATE, and a type the key's equality compares without converting it.
Nothing that can repeat a row gives a key: a set operation, VALUES, a set-returning call at that level, grouping sets, a key column passed through an expression or a cast, a join to a table that is not pinned, a FULL JOIN, a recursive WITH. A LATERAL subquery may be pinned by its key, but it is never the source of a key for the FROM around it, since its rows are computed anew for each outer row.
Views
The analysis already reads each view's definition. The proof now reads it as a subquery, with the keys, column types and functions of the tables it reads, which are asked in one more catalog round only for a statement that reads a view. A view's statement sees none of the reading statement's WITH queries.
Checks
oracle/cases/subquery_keys: 52 statements, 30maybeOneand 22 refusals, run over seeded edge values with no contradiction.--strict-coverage. One existing answer moves,json_schema_checks/view.sql, a view read by its key:manytomaybeOne.select x.title from (select * from posts) x where x.id = $1now infermaybeOne; a new unit test covers the rule and its refusals.nub run testwith both test databases: 251 pass, none skipped. The docs state the rule in the Postgres page's cardinality section, with a captured example.