Hi,

> Le 31 mars 2016 ? 11:03, Clemens Ladisch <clemens at ladisch.de> a ?crit :
> 
>> I think it is obvious I could build a SQL statement from within the
>> function and execute it. But it sounds costly to involve the parser
>> (yes, it's fast) for that, isn't it?
> 
> You can prepare the statement beforehand.

Not really. Preparing the statement involves the connection object which won't 
be known before function call. So preparation has to be done dynamically.  Did 
I really miss something here?


> Le 31 mars 2016 ? 13:32, Keith Medcalf <kmedcalf at dessus.com> a ?crit :
> 
> On the third hand, this could be a case of premature optimization and the 
> optimal course of action is not to optimize the action before doing it, but 
> as Nike says, "Just Do It".

I agree on the generic point, though here the desire to call another existing 
function from the implementation of a new one is merely a 'code reuse' point of 
view (not to re-invent/re-code things perfectly already implemented).  :)


> Le 31 mars 2016 ? 14:09, Hick Gunter <hick at scigames.at> a ?crit :
> 
> While it is technically possible to convincingly fake an SQLite context to 
> call strftimeFunc() with, it also means that you are ignoring SQLite function 
> overloading. And making yourself dependant on internal changes to SQLite 
> structures that are opaque for a reason.

I never intended to hack the code, make strftimeFunc() non static to call it 
from elsewhere (out of sqlite code). My question was: is there a supported API 
function (a single one would be enough), to relay a call to the internal 
implementation of some function.


Consider this theoretical case: in an application (not in a custom build of 
sqlite itself) I'd want to implement a function "date(...)", 
overloading/replacing the default date(). That is easy to do, and works fine. 
Now suppose I only have to check for some parameters not handled by the default 
date(), build a new set of parameters (standard looking after whatever 
conversion / preparation I had to do), call the original date() function (same 
context), get its result and forward it to my caller.

I can't.  I can't call the initial implementation (or even the previously 
stacked one - if there was a stacking which I'm not sure).  And I can't really 
built a SQL statement and execute it: if I'm using date() function in the SQL 
statement, chances are that statement will call *my* version which is current 
and not the initial implementation.

Note that I did simplify the problem I was trying to solve and reduced it to 
calls of date() taking a single parameter. Simply registering a new function 
date() taking a single parameter works fine. Calls with a single parameter call 
my implementation and calls with none or 2 or more parameters call the original 
default implementation. In this case, I have the solution. The real problem at 
hand was simpler than the generalization I posted about.

There is no bug, or problem to solve in SQLite here.  Just maybe a single C-API 
function to consider for addition at some point in the future.

Thanks you all,
-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om


Context, initial post:

> Le 30 mars 2016 ? 20:04, Olivier Mascia <om at integral.be> a ?crit :
> 
> Hello,
> 
> Writing a scalar SQL function, is there a C-level way to call some other 
> scalar SQL function?
> For instance, writing some specialized date_xyz(), could it be possible to 
> prepare some arguments and call strftime()?
> 
> I see in the code that strftimeFunc() is the implementation for the 
> predefined strftime(), and I see no huge difficulty calling it from my own 
> function, but of course it is internal (static). Did I miss something in the 
> API that would let me get a hand on it? Something like some 
> 'sqlite3_call_function(...)' which would take the function name as text and 
> let me hand it the context, count of arguments, array of them, and return me 
> somehow a sqlite_value with the result?
> 
> I think it is obvious I could build a SQL statement from within the function 
> and execute it. But it sounds costly to involve the parser (yes, it's fast) 
> for that, isn't it?
> 
> -- 
> Meilleures salutations, Met vriendelijke groeten, Best Regards,
> Olivier Mascia, integral.be/om


Reply via email to