Antony's work includes a client library change that lets perl/Java/or whatever 
run SQL on the THD.  The parser was made reentrant, you connect with null 
credential and get current THD.

Sent from my iPhone

> On Oct 13, 2016, at 1:01 PM, Andrew Hutchings <> wrote:
>> On 13/10/16 16:53, Vladislav Vaintroub wrote:
>>> On 13.10.2016 17:26, Andrew Hutchings wrote:
>>> Whilst I agree it would be a nice feature and something I've heard for
>>> years, the implementation would likely be more complex than it seems.
>>> For starters you have to consider the possibility of a procedure
>>> crashing and taking the whole daemon with it. You would likely need to
>>> fork a small worker process pool and have some kind of shared memory
>>> or socket communications for safety. In addition the implementation
>>> would have to be extremely careful not to add any potential security
>>> hole due to a zero-day in PHP or some bad input filtering for example.
>>> I'm not saying it is impossible, but it will likely be a lot of work
>>> to get right and the APIs would need to be carefully thought out.
>>> So the question becomes: is it worth spending time developing this
>>> over another feature? Or is it something that could be better
>>> implemented safely in another layer, such as in a database proxy?
>>> Kind Regards
>>> Andrew
>> I think crashing is much easier if one runs native C UDFs, or any kind
>> of natively compiled plugins.
> I don't know, I've seen some horrid things happen with interpreted languages 
> before.
>> For external languages I think an important aspect is often overlooked.
>> Namely, how to would access data. You can create a new JDBC connection,
>> but it is likely not what you want to do. You just want to run a SELECT
>> from the same session you're in, just like you do in SQL stored
>> procedures. Exactly this requires a large amount of work in the
>> connectors. It is not  just running a JVM  inside the server.  There is
>> no API for data access from the running session inside the server,  not
>> even for C.
> I was envisioning a tighter coupling than using connectors in the above. 
> Opening up the thd to a new process via a new API and blocking the client 
> whilst doing so. I hadn't really thought though the mechanics of it too much 
> though. But you are right, either way it is a lot of work.
> Again, I think this kind of thing is better suited to the application or 
> proxy layers. Especially with things such as MicroServices and Serverless 
> around which are designed to break up the logic like this (I'm not a fan of 
> the buzzword though).
> Kind Regards
> -- 
> Andrew Hutchings - LinuxJedi -
> _______________________________________________
> Mailing list:
> Post to     :
> Unsubscribe :
> More help   :

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to