Require populating each column in row-ascending order to allow rebinding multi-row fetch

[mikepizzo]

Current design allows rows and columns of a multi-row fetch to be populated in any order, so, for example, the driver could populate all rows of column 1 before any rows of column 2, etc. This is important for stores like Hive that return columns-wise data on the wire.

However, the current design supports any ordering, including returning row 1 of column 1, then row 2 of column 2, then row 2 of column 1, then row 1 of column 1. There is no clear scenario for this completely arbitrary population.

If we could at least impose that rows for a particular column are populated in order (which seems entirely reasonable), then we might be able to relax many of the current restrictions applied to dealing with rowset sizes > 1 (like the inability to rebind columns during DATA_AVAILABLE when rowsetsize > 1.)

[mikepizzo]

If app rebinds buffer, how does driver deal with offset into that buffer for multi-row fetch? For simplicity/consistency, I would assume that: 1) SQL_DESC_BIND_OFFSET_PTR cannot be changed during a DATA_AVAILABLE state 2) The driver would still start each binding at SQLDESC[DATA|INDICATOR|OCTET_LENGTH]_PTR + SQL_DESC_BIND_OFFSET_PTR + (SQL_DESC_LENGTH * SQL_DESC_COUNT) into that (new) buffer.

[mikepizzo]

Updated spec to say that rows of a given column must be populated in order and removed the restriction on rebinding if rowsetsize > 1.

Note that SQL_DESC_BIND_OFFSET_PTR is a pointer to a deferred value. Not allowing them to change the pointer doesn't prevent them from changing value it points to. We would either have to require the driver to cache the value of the offset_ptr at the beginning of the call, or just say that the driver always calculates the specified ptrs, plus offset, plus length*count, and app has to ensure this is the right/valid memory location. Note that, in multi-row fetches, changing type or descriptor length could affect that offset. Also, changing the value pointed to by SQL_DESC_BIND_OFFSET_PTR affects all columns. Application beware!

Added following caution:

• Applications SHOULD NOT change the offset value indicated by SQL_DESC_BIND_OFFSET_PTR while in a SQL_DATA_AVAILABLE state. As the driver can populate columns and indicators in any order until the fetch operations completes, changing this value while in a SQL_DATA_AVAILABLE state has indeterminate affects.