Skip to content

compiler: a scalar subquery's column is nullable - #4654

Open
ken-talltree-io wants to merge 1 commit into
sqlc-dev:mainfrom
ken-talltree-io:fix-4262-nullable-subquery-case
Open

ken-talltree-io wants to merge 1 commit into
sqlc-dev:mainfrom
ken-talltree-io:fix-4262-nullable-subquery-case

Conversation

@ken-talltree-io

Copy link
Copy Markdown

A scalar subquery yields NULL when it matches no row, but the legacy analyzer gave its column the nullability of the column it selects, so (select r.id from reviews r where r.book_id = b.id limit 1) came out non-null. This makes it nullable unless the subquery always yields exactly one row: an aggregate with no GROUP BY, HAVING or LIMIT ((select count(*) …) stays non-null), or a SELECT with no FROM.

Fixes #4262. The new nullable_scalar_subquery fixture covers a subquery through a view and inline; it fails without the change in both the base and managed-db contexts. With PostgreSQL available, every TestReplay case passes, and no existing expected output changes.

CASE … ELSE NULL::type has the same problem on this path; I've left it to #3739, which reworks CASE (see my comment there about column-reference results).

🤖 Generated with Claude Code

A scalar subquery yields NULL when it matches no row, so its column is nullable
unless the subquery always yields one row: an aggregate with no GROUP BY,
HAVING or LIMIT, or a SELECT with no FROM.

Fixes sqlc-dev#4262

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SQLC does not infer nullability for subqueries in view SELECT

1 participant