Repository navigation
Sqlite: Support for setAuthorizer #50
Description
Node documentation for the feature: https://nodejs.org/api/sqlite.html#databasesetauthorizercallback
Use case: When writing code that runs SQL, this feature would help in ensuring specific tables or columns cannot be altered or changed. It could also be used to observe access behaviors on a database without needing to worry about wrapping INSERT or UPDATE statements. I'm sure there are other use cases, but those are what come to mind.
I'm specifically opening this up given some work I've been doing on a migration package. I want to be able to block editing the migration table when the migration is happening. I currently do this by checking migration statement strings for matching the migration table name, but that is not foolproof. This, if I understand how it works, would be.
Activity
robinheghan commentedon May 13, 2026
I think this is a good feature request. The challenge is that it's not supported in Node.js V22, only in 24+.
I guess we can introduce this function as a failable task, and have it fail on platforms where the API isn't available? 🤔
joeybright commentedon May 19, 2026
@robinheghan Ah, yeah, specific Node.js version support is something I'm running into as of late (associated PR where implementation of a better password hashing algorithm is gated behind it being available only in later Node.js versions: gren-lang/core#131).
I think a failable task works, but isn't the most elegant. It'd be nice to have some sort of almost permission check for functions that have specific runtime requirements. Like
SecureContextin theCryptolibrary, but something likeSetAuthorizerSupported? This would be useful in being able to gate functionality behind the type system.Example: For the migration library I'm working on, I might want it to just not work, at all, if
setAuthorizerfunctionality isn't available. Instead of needing to run aTask, wait for it to fail, and then returning an error, themigratefunction could require theSetAuthorizerSupportedtype, which confirms that functionality is supported by the given runtime.This would be especially nice if something like
SetAuthorizerSupported(AndSecureContextbecause it was mentioned) were only able to be generated inInit. They're kinda the same - platform feature / functionality detection types. Encourages failing early if the platform you're running a program in doesn't support the thing you want to use.I'm not sure if this would be any better than a failable task, to be honest. Just a thought!
robinheghan commentedon May 20, 2026
I get what you're saying. But I think, considering Gren is still pre 1.0, that a failable task is the way to go in this case. Once v22 reaches EOL, we can remove the error.