Sqlite: Support for `setAuthorizer`

[joeybright]

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.

[robinheghan]

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]

@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 SecureContext in the Crypto library, but something like SetAuthorizerSupported? 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 setAuthorizer functionality isn't available. Instead of needing to run a Task, wait for it to fail, and then returning an error, the migrate function could require the SetAuthorizerSupported type, which confirms that functionality is supported by the given runtime.

This would be especially nice if something like SetAuthorizerSupported (And SecureContext because it was mentioned) were only able to be generated in Init. 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]

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.