Yes, you can do that but I'm trying to remove steps and conversions, not
add more. My point is that a more native interface is better than SQL.

Yes it's basic, but as I said, a first step. I'm making changes to one
part, making changes to another part makes no difference. The fork has been
forked, the die is cast.

Actually, I'm focusing on my own work which require all these things one
way or another.

On Thu, Jun 4, 2015 at 2:30 PM, Nico Williams <nico at cryptonector.com> wrote:

> 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
> --
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

Reply via email to