Repository navigation
feat(postgres): type json a with query or derived table builds - #3
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No configured credential can serve this run. Your Claude Pro/Max subscription was rejected. Sign in again by running The providers' responses
|
|
Warning Your Claude Pro/Max subscription token is revoked, so every run stops before the agent starts. Every Pullfrog run on colinhacks has failed since October 21 (5 runs, no successes), so this review did not happen. Anthropic returns "OAuth access token has been revoked" for the CLAUDE_CODE_OAUTH_TOKEN stored on your account, which means your Claude subscription authorization has expired or been revoked. The repo is set to anthropic/claude-opus, which requires a valid Claude subscription or an Anthropic API key, and no other credential is configured to serve that model. To fix it:
|
b6b18bc to
d3029e9
Compare
|
No configured credential can serve this run. Your Claude Pro/Max subscription was rejected. Sign in again by running The providers' responses
|
There was a problem hiding this comment.
ℹ️ No critical issues. Typing JSON through items looks sound, and there are two minor suggestions inline.
Reviewed changes
The branch was force-pushed to a single commit, and no earlier Pullfrog review exists, so this review covers the whole PR.
- Typed JSON through items: A JSON column read straight from a
withquery or a derived table now resolves to the type the item's own constructors build. This works in the select list and inside outer constructors, throughEngine::built/Engine::item_built, at mostMAX_ITEM_DEPTH = 4levels deep. - Added
ItemRead::Defaulted:coalesce(c, '[]')of such a column is recognized and, for an array, typed as neverNULL.item_columnstreats it as no settled read, which matches the old behavior. - Carried built JSON through probes:
jsonshape::Outcome.builtlets aShape::Columninside a constructor use the item's built type. Nullability still comes from the probe column, and inner unresolved paths are rejoined under the outer path. - Extracted
Engine::shapesandEngine::stored_checks: The probe loop and the stored-row CHECK lookup can now run once per item level. - Added the
json_item_shapesoracle case and docs: 19 statements cover objects, aggregates, renames, chains, parameters, outer joins and the shapes that stayunknown.
claude-opus-5-5 ｜ 𝕏
There was a problem hiding this comment.
✅ No new issues found. Both earlier findings are fixed, and each fix is pinned by a test.
Reviewed changes
This review covers the two commits since the last Pullfrog review (d3029e9).
- Fixed unresolv
8000
ed array paths under an outer key:
Shape::Columnnow appends an item's unresolved path that starts with[]straight onto the outer path. That givesposts[].tagsinstead ofposts.[].tags. The new resolver test checks[].tags,[]and the whole value. - Described all probes before following items:
Engine::shapesnow describes every probe inplan.probesfirst. It follows their items in a second pass. Item traces can therefore only use theMAX_PROBESbudget the statement's own probes leave, so a statement near the budget keeps the typing it already had.with_probe_budget.sqlpins this:b1–b6stay typed, andagets its item's keys withunknownleaves.
claude-opus-5-5 ｜ 𝕏
A JSON column read from a WITH query or a derived table was unknown, whatever that query built. It now has the type of the JSON the query's own statement builds, read as it is, inside JSON the statement builds, or under coalesce(..., '[]') for an array.
Following the items one probe reads before describing the next probe could spend the probe budget a later probe needed, leaving JSON the statement itself builds unknown.
e4908d4 to
6e1dc17
Compare
On Postgres, JSON a statement builds with
jsonb_build_object,jsonb_aggorto_jsonbis typed from its arguments, but only where the statement builds it. JSON built inside awithquery or a derived table and selected from outside it wasunknown. Now such a column has the type of the JSON that query's own statement builds:jsonb_build_object('posts', ps.posts),jsonb_agg(s.post));coalesce(ps.posts, '[]'), for an array, which is then neverNULL;withqueries, four deep at most.The column is as nullable as the query's own result and the joins over it make it, which is how its nullability was already settled.
with s as (select jsonb_build_object('id', id, 'title', title) as post from posts) select post from spost: jsonpost: { id: int8, title: text }with ps as (select user_id, jsonb_agg(jsonb_build_object('id', id)) as posts from posts group by user_id) select u.name, ps.posts from users u left join ps on ps.user_id = u.idposts: json?posts: [{ id: int8 }]?coalesce(ps.posts, '[]') as postsposts: jsonposts: [{ id: int8 }]select jsonb_build_object('stats', s.stats) from (select jsonb_build_object('count', count(*)) as stats from posts) s{ stats: unknown }{ stats: { count: int8 } }What stays
unknown: a column of aunioninside the query, alateralsubquery, a*over the query, andcoalesceof an object with'[]'. Undercoalesce(…, '[]')inside a constructor the array keeps its type but stays nullable.Tests:
oracle/cases/json_item_shapes: 19 statements, sound over the seeded edge values.coalesce(c, '[]')read.--strict-coverage, the loader's typecheck and tests, the package build, and the basic and JSON Schema labs.