Hi, My colleagues and I from Huawei have been experimenting with the MAL code generated by SQL explain. We noticed big differences between the code generated by version 15 and the present top-of-tree. For example, where the level-15 code tended to generate just one barrier-exit block for a simple "select *," the new code generates several. (That might have to do with views--that's my guess, anyway.) Unfortunately, whereas the "old" (level 15) code is manually executable by the MAL interpreter, the new code doesn't run directly. For example, the interpreter complains about uninitialized variables. Of course, this is straightforward to fix manually, though somewhat tedious. But we also find when running multiple-barrier code, we get many complaints about undefined things, e.g., sql.mvc(), sql.bind(), among others. We don't (yet?) know how to overcome this issue. Is this just a temporary situation, or will it be possible at some point again to manually run MAL code? (Is it a policy of the MonetDB project that explained MAL code should be manually executable?) Would it be possible to explain (briefly) the reasons for the differences between the two versions of generated MAL code? We're curious what would prompt such a big change in the generated code. Thank you, Steve Morgan P.S. I've created a version of the mapi.connect() and mapi.reconnect() code that accepts a database name as another parameter. We've used it to send RPCs between systems (Linux containers, actually). We would be happy to donate this code to your organization, if you would like it. I added a new MAL routine for mapi.connect(), i.e., SERVERconnectWithDBname() and similar things for the mapi.reconnect() calls that detects the extra parameter and uses it if it's there. It shouldn't break any existing code, and it allows one to run RPCs while using monetdbd (not just mserver5).