RFC: Expanding Access Modes #138
Description
Summary
PR #124 proposes adding a DML_ONLY access mode, which raises broader questions about our access mode design. This issue is to discuss an approach for more fine-grained restriction levels.
Current Design
We currently have two modes at opposite ends of the convenience/safety spectrum:
| Mode | Intent | Use Case |
|---|---|---|
| UNRESTRICTED | Full access | Development environments where mistakes are recoverable |
| RESTRICTED | Read-only | Production environments where safety is paramount |
We chose these two extremes deliberately, with names that describe use cases rather than technical specifics. This is because it's difficult to make precise guarantees - for example, we can restrict DDL in direct queries, but what about DDL in stored procedures or extensions?
The Gap
PR #124 identifies a real use case: application agents that need to modify data but shouldn't touch schema. This could make sense for:
- Data import/migration agents
- Application-level CRUD operations
Questions for Discussion
-
Should we add a third mode? If so, what should it be called? Alternatives:
NO_DDL,DATA_ONLY,SCHEMA_PROTECTED, something else? -
What's the framework for future modes? Is there a 4th or a 5th mode? What is the framework for them?
- Write scope: nothing → data → everything
- Trust level: untrusted → semi-trusted → trusted
- Reversibility: read-only → reversible changes → irreversible changes
- Database features: specific fine-grained controls / custom whitelist
Related
- PR Add DML_ONLY access mode #124: Add DML_ONLY access mode