I want to throw my support behind this idea in principle, that principle being that it is important to be able to invoke database stored routines efficiently and easily. In my case, considering that a dominant paradigm of Muldis D is to put all database access code in database stored routines, so having less indirection for implementing the language over existing DBMSs should only be helpful. Also as commented, the solution should support inputing or returning arbitrary configurations of data, eg, multiple subject-to-update parameters, as SQL itself supports. -- Darren Duncan

Reply via email to