3 ms·

I was wondering the same thing. And in particular if a new query language that avoided many of the pitfalls of SQL could compile down to that bytecode and avoid

by thayne 3y ago

I was wondering the same thing. And in particular if a new query language that avoided many of the pitfalls of SQL could compile down to that bytecode and avoid having to deal with SQL as an intermediate representation. Also, if you can compile to bytecode ahead of time, then that could save the time needed to parse the text of a sql query to bytecode at runtime.

nraynaud 3y ago
I'm puttig my wish list here: - be able to put the projection in a varable and reuse it (and I think orm people might love it) - have a quick way to forward the the non-aggregated fields of projection to a group by (maybe with the aforementionned variables)
- TachyonicBytes 3y ago
  The DuckDB API I was talking above seem to already meet your use-cases? - Does this[1] solve the group by wish? - Depending on what you mean by projection, maybe this[2] or this[3]? [1] https://duckdb.org/docs/api/python/relational_api#aggregateexpr-groups-- https://duckdb.org/docs/api/python/relational_api#aggregatee... [2] https://duckdb.org/docs/api/python/relational_api#projectexpr https://duckdb.org/docs/api/python/relational_api#projectexp... [3] https://duckdb.org/docs/api/python/expression#column-expression https://duckdb.org/docs/api/python/expression#column-express...
  - nraynaud 3y ago
    that's really great!
forinti 3y ago
A client-server database would hash the SQL and cache the output of the parser. The end result is the same. Maybe SQLite could have a similar mechanism, but the cache stays on disk or an external memory cache.
- gwbas1c 3y ago
  In the C# library for SQLite, a DbCommand with parameterized SQL can be reused, thus reusing the bytecode.
astrobe_ 3y ago
> Also, if you can compile to bytecode ahead of time, then that could save the time needed to parse the text of a sql query to bytecode at runtime. I think we already kind of have that already; one can prepare a query/statement and then use it multiple times. Regex engines also do that, except that in the case of SQlite one can bind different parameter values. Programmers worried about SQL lexing/parsing times can compile their most used queries once for all at programmer startup. Plus, one can sometimes break a query with annoyingly variable parts into smaller queries glued with SQLite API calls.
TeMPOraL 3y ago
> Also, if you can compile to bytecode ahead of time, then that could save the time needed to parse the text of a sql query to bytecode at runtime. That's exactly how those "prepared statements" work in SQLite - you get a handle to a piece of bytecode, and you can call it with different parameters.

by thayne 3y ago

nraynaud 3y ago

I'm puttig my wish list here: - be able to put the projection in a varable and reuse it (and I think orm people might love it) - have a quick way to forward the the non-aggregated fields of projection to a group by (maybe with the aforementionned variables)

TachyonicBytes 3y ago
The DuckDB API I was talking above seem to already meet your use-cases? - Does this[1] solve the group by wish? - Depending on what you mean by projection, maybe this[2] or this[3]? [1] https://duckdb.org/docs/api/python/relational_api#aggregateexpr-groups-- https://duckdb.org/docs/api/python/relational_api#aggregatee... [2] https://duckdb.org/docs/api/python/relational_api#projectexpr https://duckdb.org/docs/api/python/relational_api#projectexp... [3] https://duckdb.org/docs/api/python/expression#column-expression https://duckdb.org/docs/api/python/expression#column-express...
- nraynaud 3y ago
  that's really great!

forinti 3y ago

A client-server database would hash the SQL and cache the output of the parser. The end result is the same. Maybe SQLite could have a similar mechanism, but the cache stays on disk or an external memory cache.

gwbas1c 3y ago
In the C# library for SQLite, a DbCommand with parameterized SQL can be reused, thus reusing the bytecode.

astrobe_ 3y ago

> Also, if you can compile to bytecode ahead of time, then that could save the time needed to parse the text of a sql query to bytecode at runtime. I think we already kind of have that already; one can prepare a query/statement and then use it multiple times. Regex engines also do that, except that in the case of SQlite one can bind different parameter values. Programmers worried about SQL lexing/parsing times can compile their most used queries once for all at programmer startup. Plus, one can sometimes break a query with annoyingly variable parts into smaller queries glued with SQLite API calls.

TeMPOraL 3y ago

> Also, if you can compile to bytecode ahead of time, then that could save the time needed to parse the text of a sql query to bytecode at runtime. That's exactly how those "prepared statements" work in SQLite - you get a handle to a piece of bytecode, and you can call it with different parameters.