Basically, all I do is call each query in turn until I've collected all the results, then marshall the results in to a SOAP XML response (using gsoap, if anyone's curious) and give them back to the client application. It's the client app's job to figure out what to do with them, not mine. I never would have written it this way on my own, but the client app is already written, so as I migrate it to the client-server model, the programmers who wrote the client app are specifying what they expect me to provide them.
In C++/OO way, that would have been a array/list of base object pointers with virtual methods for
- Obtaining result set
- Making a soap/XML out of it
- Deliver it
- And pre/post processing
And delegate the unique query/data handling to specific subclasses.
Now that you are doing that in C, you can as well use function pointers to mimic inheritance and virtual functions. The only difference being
a. No typechecking. A function pointer in C, won't crib if you pass it wrong number/wrong types of argument. C++ compiler will catch that.
b. Maintainance is nightmare unless you thoroughly document it. In C++, glancing over source code might suffice. And no, in-source comment rarely suffice when you use C for such applications.
I maintain such an application for day-job and I know what help/menace it can be at times..:-(
But either way, asking for/using/maintaining non-homogeneous recordset is a classic three finger salute. Load the gun, point to head and shoot.
Just a thought..
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match