Hello.
I like about Java filters:
1. Create a filter object. Prepare it as much as you can.
2. Filter the data thrue the object filter.
3. Destroy the filter object.
Objects are inefficient to create and destroy very many times.
With a filter object, you can create and prepare the filter once,
and then use that filter for the whole data stream.
So the idea for a fast data conversion for SQL SELECTs is this:
1. SQLPrepare()
=> create a filter object.
=> Find out about column types as much as you can.
=> (Alternatively find out the information from the first query result row.)
2. SQLBindCol() calls.
=> write into the filter object the needed column binding information and
resolv the needed conversion function, for example cvtInt4toWChar()
3. SQLExecute() call
=> Use the filter object in stmt->select_filter for each result row.
4. Return into SQLBindCol() phase.
So here is what needs to be made:
Create files query_convert.h and query_convert.c.
Create files converters.h and converters.c for cvtInt4toWChar() style
functions.
converters.h has also one huge function, that can do bool->char->int4
two-phase
conversions. It calls for example both cvtBooltoChar() and
cvtChartoInt4() functions.
query_convert.h contains the following function definitions:
QC_new()
QC_destroy(qc)
QC_SetBackendType(qc,colIdx,type)
QC_GetBackendType(qc,colIdx)
QC_SetBindType(qc,colIdx,type)
QC_GetBindType(qc,colIdx)
QC_ConvertItem(qc,colIdx,source,dest)
QC_ConvertRow(qc,source,dest)
QC_ConvertRowSet(qc,srcRowset,destRowset)
So, for each row, the filter needs to call the cvtXXX function to do the
conversion.
It won't need to be resolved every time. Functions are also simple, but
there are many functions.
If the converter functions (backend->Int4 are local for SQL selects, and can
not be reused for inserts or updates, they need not be in common C file,
in the conversions.c/h.
What do you think about this?
In my opinion this would be easier to understand
than the current implementation.
You could also put the data via many filters:
you could possibly implement a distinct charset filter on the client
side also.
Marko Ristola