Generic SQLite Result Function? (C) - c

Question

I'm programming server software in C, and I'll have around 8 functions that select data from an SQLite database and handle it in some way. I'm considering making one function to send any kind of SQLite SELECT command and return its results as a 2D array of pointers to integers and strings then having all the functions use that, but I'm worried that the performance cost might be so large that it's not worth the extra expandability. Reading ahead, is performance a valid concern here?
SQLite has no way of counting the rows of a result ahead of time, so I'd have to either run two queries or use a dynamically-allocated array. Not good! Here is what I have for my implementation of the latter option. I'm a newbie, so please tell me if there is anything slow, unclean, or (most importantly) unreliable about this before I commit to using it:
//emalloc and erealloc are just error-detecting malloc and realloc
ptrdiff_t** databaseSelect(char* command){ //returns null upon error
sqlite3_stmt *stmt;
int retval = -1; retval = sqlite3_prepare(db,command,sizeof(command),&stmt,NULL);
if(retval!=SQLITE_OK){
printf("Selecting data from database failed! Error: %s\n", sqlite3_errmsg(db));
return NULL;
}
int retRows = 10; //number of rows in returned array for now
ptrdiff_t** ret = emalloc(sizeof(ptrdiff_t*)*retRows); //make the array representing rows
int result = SQLITE_ROW;
int rowIndex = 0;
while (result != SQLITE_DONE && result != SQLITE_ERROR){
result = sqlite3_step (stmt);
if (result == SQLITE_ROW) { //begin row loop
if ((rowIndex+1)>retRows){ //must reallocate the outer (row) array
retRows*=2;
ret = erealloc(ret, sizeof(ptrdiff_t*)*retRows);
}
const int numCols = sqlite3_column_count(stmt);
ptrdiff_t* row = emalloc(sizeof(ptrdiff_t)*numCols); //make the array representing a row of columns
for (int colIndex = 0; colIndex<numCols; colIndex++){ //begin column loop
switch (sqlite3_column_type(stmt, colIndex)){
case SQLITE_INTEGER:{
const int col = sqlite3_column_int(stmt, colIndex);
memcpy(row[colIndex], &col, sizeof(col));
break;
}
case SQLITE_TEXT:{
const unsigned char* textResult = sqlite3_column_text(stmt, colIndex);
const size_t textSize = (strlen(textResult)+1)*sizeof(char); //edited from before
row[colIndex] = emalloc(textSize);
memcpy(row[colIndex], textResult, textSize);
break;
}
default:{
//perhaps warn about an error since it should either be integer or text
break;
}
}
} //end column loop
ret[rowIndex] = row; //add on the row to the array of rows
rowIndex++;
} //end row loop
}
sqlite3_free(stmt);
return ret;
}
… And then whatever calls this function has to loop through the 2D array and free everything once it's done with it.

Answer 1

For smallish results, performance does not matter.
Reallocating with a constant factor is one of the most efficient ways of creating a dynamc-sized array. Creating a linked would be faster, but not as easy to access later.
A cursor would be an object that allows access (only) to the current record, but this does not work if you need random access to all result records.
Please note that the most efficient way to determine a text value's length is sqlite3_column_bytes:
char *textResult = (char *)sqlite3_column_text(stmt, colIndex);
if (!textResult) textResult = ""; // handle NULL (if needed)
int textSize = sqlite3_column_bytes(stmt, colIndex) + 1;