[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SQLite interface
From: |
Kenneth Raeburn |
Subject: |
Re: SQLite interface |
Date: |
Sat, 15 Mar 2014 02:53:04 -0400 |
On Mar 13, 2014, at 16:31, Florian Weimer <address@hidden> wrote:
> * Ted Zlatanov:
>
>> Given that any possible FFI interface is after the freeze and probably
>> will take months to get into a released Emacs, can you consider writing
>> this with a shell backend for now and use the C API opportunistically?
>
> What does this mean? Do you want me to write a stub for the SQLite
> API that runs as a subprocess and exposes that over some sort of RPC
> interface?
A Perl stub using DBI and DBD::SQLite, with communication in JSON or YAML or
some such (or s-expressions, if Perl module Data::SExpression is fully Emacs
compatible even for untrusted and binary or multibyte-text data), may not be
all that much work.
>> I don't know the details about SQLite's accessibility, but I believe it
>> can do at least some useful things non-interactively over STDOUT/STDIN.
>
> Oh, you want me to use the existing sqlite3 command line client?
> That's a non-starter. It is not binary-transparent, and it does not
> separated support query parameters. My planned use case (Gnus)
> handles untrusted data received over the network, so this approach
> does not seem such a good idea to me.
I suppose using SELECT QUOTE(CAST (column AS BLOB)) ... and INSERT ...
CAST(X'010203' AS TEXT), passing values as hexadecimal, would be horribly
intrusive when writing the queries and processing the results, but is there
more than that needed to use the command line client?
Ken