[freetds] results processing in freetds

ZIGLIO Frediano Frediano.Ziglio at vodafone.com
Wed Oct 8 18:02:35 EDT 2003


> 
> Hi Freddy,
> 
> as usual , you manage to get across a lot of information in 
> just a few sentences, unlike me!
> 
> let me try and get what you've said straight in my own head....
> 
> > I  think we should work on curr_resinfo.. This pointer point to 
> > current
> result and can be res_info or cur_dyn->res_info. token.c just 
> write to curr_resinfo (or it should)... 
> 
> So - you're saying that token.c should just operate on 
> tds->curr_resinfo , and should never set tds->curr_resinfo - 
> that being responsibility of whatever calls the token.c functions...
> 

Mmm... perhaps query.c should set tds->curr_resinfo. Perhaps
tds->curr_resinfo should be a TDSRESULTINFO ** and by default point to
tds->res_info ?

> > When we want to get some rows from cursors we just set 
> curr_resinfo to 
> > our
> cursor->res_info.
> 
> And the implication is that when we wanted to get some rows 
> from a normal query, we would have to set curr_resinfo to 
> tds->res_info
> 
> > Problem is compute. I think is a good idea to add a TDSCOMPUTEINFO
> **comp_info to TDSRESULTINFO structure and remove from TDSSOCKET. 
> 
> Interested to know why you think they are a problem. If I 
> told you that "compute" clauses are forbidden in SQL 
> statements used to open cursors, would the problem go away ?
> 

Yes, for cursors. I never thought about this problem... I think dynamic
can return select with compute so we have found a new bug...

> > This was just prepared for cursors as declared in an very 
> old mail...
> strangely you add curr_resinfo for this stuff..
> 
> I don't understand what you're saying here.
> 

We worked on a similar issues (reslts from dynamic and compute) and you
wrote the code :)

> Some other points:
> 
> 1) We'll need an array or linked list of TDSCURSORINFO 
> structures, as you can have more than one open cursor on the 
> connection.
> 

Yes, I think an API similar to dynamic one (add three fields to tds:
num_cursors, cur_cursor, cursors).

> 2) token.c (tds_process_result or other) will have to 
> allocate the TDSRESULTINFO storage, as only it knows how many 
> columns have been returned in the result set.

Yes, this is why cur_resinfo should be a pointer to pointer.

>     How's it going to know which TDSRESULTINFO * should point 
> to the allocated storage ? remember the results token from a 
> cursor open looks just like an ordinary results token...
> 
> 
> Thanks for the help Freddy...
> 
> 
> Bill
> 

Perhaps we should also remove tds->param_info ?? It's just another
result... Perhaps we should also add a type field (params, row, compute
row) to TDSRESULTINFO. About ret_status/has_status: these fields make
sense in both dynamic and connection; any library can ask return status
referred to a dynamic ? As a C++ programmer I'm thinking about something
like this:

class Result { ... };

class ParamResult: public Result { ... };

class RowResult: public Result { ... };

class ComputeResult: public RowResult { ... };

class tds
{
...
private:
	Result *cur_resinfo;
...
};

freddy77


More information about the FreeTDS mailing list