D. Richard Hipp wrote: > 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. ;-)
I wasn't sure how much type information SQLite gathered about the literals it needs to be assigned to parameters. If there is none, then this API doesn't make much sense after the statement is prepared, but it is still needed to determine the parameter's type after it has been bound to a particular value (with a manifest type). That type may be needed to call the correct parameter data readback function. > 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 > occurrences of the same named parameter means that the name->index map > is not unique so the function above will not work. The name to index mapping must be unique and one-to-one. The idea is to have a single parameter value with a name that may appear multiple times in the SQL statement. Every occurrence of that name in the statement is replaced with the bound value when statement is executed. That is why SQLite must scan the parameter list each time it parses a parameter name in the statement. It must check if it has already assigned an index number to this name, or if it needs to assign a new index number for a new name. The index numbers are used internally in the VDBE code that is generated to execute the statement. The client application then only needs to bind the value of the parameter once, not once for each time it appears in the original SQL statement. > 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. No, that's what happens when you add a quick comment without giving it enough though. You are right, it makes much more sense to leave all parameters with there current value after a reset. If the user want to change any value they can use the bind API to change just the parameters that need to change, and they can set them to null if they want. This way only the values that need to change are modified, rather than having SQLite change them to null, and the user change many of them back to their previous value. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
