Skip to content
This repository was archived by the owner on Jun 2, 2025. It is now read-only.

Make query translation more restrictive #15

Closed
JanJakes opened this issue Feb 12, 2025 · 1 comment
Closed

Make query translation more restrictive #15

JanJakes opened this issue Feb 12, 2025 · 1 comment

Comments

@JanJakes
Copy link
Contributor

The current query translation approach is rather minimalist, handling some differences between MySQL and SQLite, while leaving other/unknown syntax to fall to default translation handling and relying on the SQL dialect similarities.

For better confidence and data safety, it would be better to implement a more "allowlist"-oriented driver that would be explicit about what syntaxes are supported, leaving the rest as "unsupported". This is needed especially for data-writing queries, less so for read-only queries, in the following order of importance:

  1. DDL queries — here it's very important to allow only what we support to keep the information schema consistent.
  2. Data-writing queries — it can be important in some cases where an incorrectly understood query would result in a wrong operation.
  3. Read-only queries — here, allowlist can be a convenience (bail out early) rather than a necessity.

The full MySQL grammar contains many nodes, variations, and nesting, and it's hard to handle every detail using an allowlist — for instance, a specific construct may be generally valid in an expression, but not in an expression in a subquery in a join, etc. That said, I think we can be very explicit at the higher level — explicitly stating which top-level statements we do support and which ones we don't, and which main subconstructs of these statements are supported or not (e.g., LIMIT clause in a DELETE query).

See: #1 (comment)

@JanJakes
Copy link
Contributor Author

JanJakes commented Jun 2, 2025

@JanJakes JanJakes closed this as completed Jun 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant