IMHO, SQLite is targeted towards being a relational "core" with very
wide extensibility. Adding specific scripting engines to it is would be
detrimental to its main purpose (being a very good relational "core").
In our group, we use SQLite + UDFs written in Python. Creating new
functions is very simple (most of the functions are a couple Python
lines). The API of SQLite permits very advanced functionality to be tied
to it (infinite streaming virtual tables, indexes written in Python,
etc). And (in our benchmarks) the speed is better than Postgres and a
LOT better than MySQL.
Finally, the simplicity and extensibility of SQLite has permitted us to
create hundreds of functions in a very short time [*].
l.
[*] http://doc.madis.googlecode.com/hg/index.html
On 07/03/14 16:59, Dominique Devienne wrote:
On Fri, Mar 7, 2014 at 3:39 PM, Clemens Ladisch <clem...@ladisch.de> wrote:
Max Vlasov wrote:
On Fri, Mar 7, 2014 at 12:49 PM, Dominique Devienne <ddevie...@gmail.com> wrote:
I think what SQLite lacks is a syntax to define custom function like
it does for virtual tables. Something like:
create function rpad(x, y) using scripty_module as "return PRINTF('%-*s',y,x)";
Nice suggestion. This probably falls into case when a small new part
needed on sqlite side
Actually, no change to SQLite itself would be needed. It's possible
to create an extension that provides a function that allows to register
another function that executes a custom SQL expression:
SELECT register_simple_function('rpad', 2, 'SELECT printf(''%-*s'', ?, ?)');
I've already mentioned that Clemens. But also pointed about that then
you don't have a standard way to register those dynamically generated
functions. FWIW. --DD
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
