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

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

Reply via email to