[sgbeal]

> there is no need to cling to SQL. It is merely an implementation detail.

It is, in fact, also the interface. To use your example of SQLite bytecode: once your tool generates it, there is no way to feed that into SQLite. The bytecode is an implementation detail, with SQL being the public interface.

[randomdata]

But, to stick with your example, you can then modify SQLite to accept byte code input – or straight up write your own database engine that uses said byte code. We already know how to solve that kind of problem. This is, comparatively speaking, child's play.

It is recognized that SQL as a target would theoretically provide a less labour intensive path for reasons of integrating into what already exists, but that only holds if natural language to SQL gets solved, and is not enough harder to solve than an alternative target.

A reasonable stretch goal, but if another target gets you there first, it would be foolhardy to cling to SQL. Replacing the database interface is a much simpler problem to solve.