FreeTDS Development Group

[Mark Schaal <mark AT champ.tstonramp.com>]

> 
> 
> Mark,
> 
> Basically it is simple for single result queries.  tds->res_info is
> defined if there are results. However, this structure has to hang around a
> while after the results are processed so things like row counts, retrun
> statses, and all that garbage can be checked. So, for multi result
> queries and subsequent calls to tds_process_result_tokens() after
> everything is done we can't clear it (until the next query is sent). 
> 
> Perhaps, what is needed is a tds->results_exist similar to the
> res_info->rows_exist that is used for DBROWS()? This would allow you to
> always know whether the previous result processing found anything or not
> and could be cleared on a call to tds_process_row_tokens already in the
> TDS_COMPLETED state, allowing ct_results to tell the difference without
> the hokey 'empty_res_hack' flag I just introduced.
> 
> What do you think?
> 
> Brian

I think tds_process_result_token() needs to be redesigned slightly, 
but I'm not sure what are the needed/correct changes.  The current
ct_results() hack isn't pretty.  If we need a hack I'd prefer having
it in the TDS layer rather than the client libraries.

One thing is that I suspect tds_process_result_token() ideally should
return twice on an empty select query - once after the result setup
information (col_names,col_info) and once for the end token.  Well,
I know it returns twice now so I should say the returns should better
reflect the actual token reads.  Currently for an empty result the end
token is read in the first call but for a non-empty result the end token
is read in the second call.  This complicates the logical flow, e.g.
this means we can't free res_info on an end token since it might really
have been a col_names+col_info+end_token instead.

Of course I'm being influenced by how ctlib views things and need to
check dblib compatability.

Another thing is that I keep hearing this whisper in the back of my mind
that says "what about compute results?" and that adds complications.
For a while I was considering a tds->result_type or res_info->result_type
which could be set to REGULAR, COMPUTE, NONE, etc., but when I ran what I
hoped would be a simple compute query "select id from items compute max(id)"
I got something like:
        col_names
        col_info
        token_167       (some compute token)
        token_168       (compute col_info?)
        regular rows...
        compute row
which interleaves regular and compute info which I didn't expect.  I don't
know if anyone much uses "compute" but I'd like to at least make it easy
for future support.

Mark
-- 
Mark J. Schaal                                  Phone:      (909) 620-7724
TST On Ramp                                     Fax:        (909) 620-8174
System Administrator                            E-Mail: mark AT tstonramp.com