On 4/10/07, Dan Kennedy <[EMAIL PROTECTED]> wrote:
I checked the code and conflict handling mechanisms (OR ERROR, OR ABORT, OR REPLACE) do not apply to virtual tables.
<snip>
Something to think about anyhow... Do we want conflict handling for FTS (and other virtual modules)?
I think OR REPLACE would be really unfortunate to lose, it's a pretty common idiom (especially using REPLACE in place of INSERT). Do we really need to have this expressed in the API? If the virtual table returned SQLITE_CONSTRAINT from xUpdate(), and guaranteed that the table was unmodified, then the core should be able to implement all of the variants. I can see how expressing it in the API might allow certain implementations to be more efficient. Admittedly, that is a pretty subtle thing to do. I think that for fts-like virtual tables, it might be reasonable, because there's a core table which can be used to enforce constraints. The current fts2 code handling UPDATE would have to be modified somewhat. -scott ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
