On Fri, Mar 7, 2014 at 11:29 AM, Max Vlasov <max.vla...@gmail.com> 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 and large DSL specific features depending on the
> side of the registered module. But you still needs some binary module
> for your functions to work.
[DD] Right. But I'd expect such modules to appear for
tcl/lua/python/ruby quickly. There's not much glue code needed on the
module side, basically unpacking the sqlite3_value into an equivalent
scripty value, and eval the script, converting back the resulting
scripty value into a sqlite3_value via result context, as usual for C
extension function.
> How about "macro expression substitution" feature? Something that
> could accept any expression compatible with sqlite as the function
> body to be just translated into corresponding vdbe instructions.
I did think of a "native" SQLite "scripting", but didn't think of
using SQL expressions SQLite already support. Very interesting.
> For example,
>
> Create function complexcase(x,y) as Case when x < 10 then y else y + 10 end
> ....
> Select complexcase(myField1, myField*10) from t;
>
> On sqlite site, the engine can only syntax check for the create
> function body, but the referencing it in actual query would require
> actual substitution with the corresponding context-sensitive errors.
That's the difficult part probably. And it's still compatible with
using create function ... using module syntax. w/o "using module" you
are using the implicit and native SQL-based syntax as the "scripty"
part.
> This definitely will be more constly in kB on sqlite side than module
> approach, but would create a more universal solution.
>
> Just quick thoughts, probably there are plenty of obstacles here :)
Which makes it more likely not to happen unfortunately. Whereas a
simple create function func(args...) using module as
module_specific_source_code would require much less code in SQLite
core, and just a sqlite3_module_v2 that extends sqlite3_module with
two new callbacks for scalar and aggregate functions registrations,
with bump of sqlite3_module.iVersion for BC. Ideally SQLite would gain
a pragma to list functions, something I've long wished for. More
wishful thinking basically :) --DD
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
