Dennis Cote wrote:

The API should provide functions that allow the application to inspect the number, type, and names of the parameters that were discovered while parsing the SQL. These functions could be called any time after the statement is prepared.

    int sqlite3_param_count(sqlite3_stmt* stmt);
    int sqlite3_param_type(sqlite3_stmt* stmt, int iParm);
    const char* sqlite3_param_name(sqlite3_stmt* stmt, int iParm);

The 1st and 3rd APIs above will work, but not the second. Remember, SQLite 3.0 will have manifest typing, which means that type of the data can change from one row to the next. Type is not associated with a column, as in standard SQL. So there is no way to know the type in advance.

Manifest typing is a feature, not a bug.  The static typing design
of SQL is the bug.  ;-)

You have the value data pointers declared as static char and void pointers. I believe they should be const pointers.

You're right. A typo.

I would propose adding a second set of parallel API functions that would
allow the application to bind the parameters by name for those cases (likely
far more common) where the application knows the names of the parameters

This second set of these bind functions could be eliminated by the use of a
single new API function that would return the index for a parameter given
its name.

int sqlite3_param_index(sqlite3_stmt* stmt, const char* name);

Someone earlier suggested that the same named parameter could occur in multiple places in the input SQL, but you should only have to bind it once. That argument makes sense to me. But allowing multiple occurrances of the same named parameter means that the name->index map is not unique so the function above will not work.

A statement's parameter values would be reset to null values when the statement is reset.

Is that really the desired behavior? If you want to reset parameters on a statement reset, wouldn't it be better to do so explicitly. That way, if a statement has 10 parameters, and you want to execute it 10 times, and only one parameter changes between each run, you do not have to reinitialize the other 9 every time.

-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to