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