On Thu, Jun 04, 2015 at 02:16:22PM -0700, Darko Volaric wrote:
> {
> operation: "insert"
> table: "blah"
> columns: ["a", "b", "c"]
> values: [1.3, 2.0, 3.1]
> on-conflict: "replace"
> }
I do this all the time. It's trivial enough to generate SQL from that
sort of thing. If you have an AST then you can trivially map the
AST<->a JSON/XML/ASN.1/whatever schema.
But I don't think ease of alternative representation is the winning
argument for wanting the engine core to use an AST. It's only
convenient.
The winning argument is that working with an AST makes some tasks easy
that are otherwise hard (e.g., common sub-expression elimination).
> [...] Why are people who come from the websphere
> learning SQL syntax? [...]
Because it's standard.
> The feature I'm working on now, as a first step, basically feeds the parser
> tokens so I don't have to generate a query string. [...]
That seems rather basic, not really good enough. It must save some
allocations. But is it worth forking SQLite3 for this?! Whatever you
do with a fork, it's got to be worth it. Forking is quite hard, so
every change has got to be worth the effort.
Switching to an AST is going to require more allocations (and much more
developer effort), that's for sure. But then, this is in statement
compilation, which should not be the most critical component.
Anyways, this is all very far afield from UDTs. If you want to fork to
add UDTs, focus on that first.
Nico
--
