Found while researching whether trilean-sql's SQLite dialect could be used against Cloudflare D1 (novus-power/hive#1538, novus-power/hive#1456).
DIALECT_CONFIG.sqlite (packages/trilean-sql/src/options.ts) unconditionally compiles matches/notMatches to REGEXP/NOT REGEXP. That's documented as requiring the caller to register a regexp(pattern, value) function on the connection — reasonable for a driver like better-sqlite3, where that's possible. But some SQLite-wire-compatible targets have no way to register a custom function at all: Cloudflare D1's Workers Binding API doesn't expose that hook (confirmed against D1's own docs; still open as cloudflare/workers-sdk#2802). Against a target like that, compilePredicateNode still compiles clean and only fails at query execution time with no such function: REGEXP — worse than the compile-time UnsupportedNodeError every other unpushable shape gets.
findUnpushableNodeKind exists specifically so a caller can find out ahead of time whether a tree is fully pushable. Right now it can't tell them this, because whether REGEXP is actually callable isn't a property of the node kind, it's a property of the target connection — the same category errors.ts already carves out as "not detectable by a walk over node kinds," just currently unhandled rather than surfaced.
Suggestion: add a compile option (e.g. sqliteRegexpAvailable?: boolean, defaulting to true to preserve current behaviour) that, when explicitly set false, makes the SQLite dialect refuse matches/notMatches with UnsupportedNodeError at compile time instead of emitting SQL guaranteed to fail. A caller targeting D1 (or any other registration-less SQLite target) sets it once and gets the same clean fallback-to-in-process behaviour every other unpushable construct already gets.
Found while researching whether trilean-sql's SQLite dialect could be used against Cloudflare D1 (novus-power/hive#1538, novus-power/hive#1456).
DIALECT_CONFIG.sqlite(packages/trilean-sql/src/options.ts) unconditionally compilesmatches/notMatchestoREGEXP/NOT REGEXP. That's documented as requiring the caller to register aregexp(pattern, value)function on the connection — reasonable for a driver like better-sqlite3, where that's possible. But some SQLite-wire-compatible targets have no way to register a custom function at all: Cloudflare D1's Workers Binding API doesn't expose that hook (confirmed against D1's own docs; still open as cloudflare/workers-sdk#2802). Against a target like that,compilePredicateNodestill compiles clean and only fails at query execution time withno such function: REGEXP— worse than the compile-timeUnsupportedNodeErrorevery other unpushable shape gets.findUnpushableNodeKindexists specifically so a caller can find out ahead of time whether a tree is fully pushable. Right now it can't tell them this, because whetherREGEXPis actually callable isn't a property of the node kind, it's a property of the target connection — the same category errors.ts already carves out as "not detectable by a walk over node kinds," just currently unhandled rather than surfaced.Suggestion: add a compile option (e.g.
sqliteRegexpAvailable?: boolean, defaulting totrueto preserve current behaviour) that, when explicitly setfalse, makes the SQLite dialect refusematches/notMatcheswithUnsupportedNodeErrorat compile time instead of emitting SQL guaranteed to fail. A caller targeting D1 (or any other registration-less SQLite target) sets it once and gets the same clean fallback-to-in-process behaviour every other unpushable construct already gets.