FreeTDS Development Group

[ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>]

> 
> Brian, Freddy,
> 
> I was starting to work on row buffering.
> 
> My problem is the compute rows which I am now able to process.
> These may be interspersed with the data data rows which they summate.
> 
> having taken a look at it, I reckoned that the row buffering 
> logic assumed
> the following:
> 
> 1) that all the rows it would be buffering would be of the 
> same type, and
> 2) that they could all be described by the "resinfo" structure.
> 
> I was thinking of reworking the buffer to be a linked list of 
> structures.
> Those structures being roughly :
> 
> struct rowbuffer {
> int rowtype;        /* regular row or compute row */
> int compute_id;  /* which compute statement does this entry 
> relate to */ 
> byte *data;
> struct rowbuffer *nextptr;
> }
> 

But doing so I had to scan the list for every row readed...
The problem is TDSCOLINFO do not store information for the column but also
for data...
These fields:
- column_cur_size
- column_textpos (where's used)
- column_text_sqlgetdatapos
- column_textptr
- column_timestamp
- column_textvalue
are all data dependend, not column dependent.

I think another solution is move these field to structure inside
current_row. This change only the way text/image/blobs are handled... I
suggest a structure like

typedef struct {
        TDSSMALLINT column_cur_size;
        TDS_CHAR column_textptr[16];
        TDS_CHAR column_timestamp[8];
        TDS_CHAR *column_textvalue;
} TDSLARGETYPEINFO;

Also you should add a column_cur_size for all variable size types (note:
variable not nullable as INTN, null bit can be stored with other null
information). This should not be a big problem...

> would this type of approach handle Freddy's problem ?

No this not solve your problem, not mine (already solved in CVS, I simply
relocate null information). You store different current_row instead of only
one, but when a new row are readed you lose (i.e.) the current column size
(store with column information)...

IMHO we should separate code to handle the row size (allocation, relocation,
free) and store all data information in current_row.

freddy77

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================