The only really new API here is big_typed_query and the streaming variants, but I think all the query variants except the basic query() function should follow the same API for consistency.
Still, it ought to be possible to do away with the Sql.Sql wrapper. That might need changes in some of the db specific implementations, but if there are compatibility issues with that they shouldn't be worse than that #pike compat goo is an acceptable solution.
There is a type problem if we try to remove the Sql.Sql wrapper, though: The base class for the db specific variants should be Sql.Sql to get the typing correct, but that means its create function would have to replace itself with a different object. An easy and fairly passable way to deal with that is to allow create() to return the object that should be the result of the clone operation. That's only ugly because it unnecessarily instantiates an Sql.Sql object solely to call create() in it. True static functions would be nice.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-10-13 23:12: Subject: Re: MySQL big_query in 7.7
Looking at other aspects of the Sql module I think it might be an idea to dispose of the wrapper. Instead of having Sql.Sql wrap Sql.* that inherits C-code, we could have the C-modules inherit Sql.DB and then let Sql.open create the actual objects (from Sql.* programs). That way we can access database specific functions directly and remove one level of indirection when calling API functions. Since the access API is a new one, we can redesign whatever we want...
/ Martin Nilsson (DivX Networks)