What is the problem this feature will solve?
SQLite can invoke JavaScript through registered SQL functions during operations such as database.applyChangeset(), even when no filter or onConflict callback is supplied. For example, applying a row can evaluate a CHECK constraint that calls a JavaScript function.
This makes it unsafe to infer that an operation cannot execute JavaScript solely from the absence of explicit callbacks.
PR #65870 addresses changeset buffer safety by copying non-empty changesets before applying them. Tracking registered functions would support follow-up work on callback safety and potential optimizations.
What is the feature you are proposing to solve the problem?
Add internal tracking of JavaScript-backed SQL functions registered on each DatabaseSync instance, including scalar and aggregate/window functions.
The tracking should remain accurate when functions are replaced and when the database is closed or reopened.
Use this information to inform operation-specific safety checks. Any optimization that skips defensive copying must also account for other paths that can invoke JavaScript.
Preventing function execution should be considered separately, with explicit compatibility review: existing schemas may depend on these functions in constraints, triggers, or expressions.
Refs: #65870 (comment)
What alternatives have you considered?
Continue applying operation-specific protections without tracking registered functions. For changeset application, unconditional copying preserves existing function behavior while protecting the input buffer.
What is the problem this feature will solve?
SQLite can invoke JavaScript through registered SQL functions during operations such as
database.applyChangeset(), even when nofilteroronConflictcallback is supplied. For example, applying a row can evaluate aCHECKconstraint that calls a JavaScript function.This makes it unsafe to infer that an operation cannot execute JavaScript solely from the absence of explicit callbacks.
PR #65870 addresses changeset buffer safety by copying non-empty changesets before applying them. Tracking registered functions would support follow-up work on callback safety and potential optimizations.
What is the feature you are proposing to solve the problem?
Add internal tracking of JavaScript-backed SQL functions registered on each
DatabaseSyncinstance, including scalar and aggregate/window functions.The tracking should remain accurate when functions are replaced and when the database is closed or reopened.
Use this information to inform operation-specific safety checks. Any optimization that skips defensive copying must also account for other paths that can invoke JavaScript.
Preventing function execution should be considered separately, with explicit compatibility review: existing schemas may depend on these functions in constraints, triggers, or expressions.
Refs: #65870 (comment)
What alternatives have you considered?
Continue applying operation-specific protections without tracking registered functions. For changeset application, unconditional copying preserves existing function behavior while protecting the input buffer.