[R-sig-DB] [PATCH] segfault in RSQLite 0.5-4

[Ashish Kulkarni]

> Keep us posted.  The test is an artificial attempt to trigger the need
> for schema reload/reprepare when multiple connections to a DB are
> present.  The use case is real, not sure how good the test is.  Thanks
> again for looking into it.

Upon further investigation, I think that this test falls in a grey area.
The error returned by SQLite is actually "table not found". 
The use case for schema reload is already in testSchemaChangeDuringQuery() 
and the patched code successfully passes it. In fact, I experimented with
adding a column to the same table against which the query was prepared,
and it worked. 

The test checks for something else: whether a table added in one connection
is immediately visible in another connection. Leaving aside the fact that
this would be a very rare scenario, I think that SQLite should reload
the schema information before reporting "table not found", which it is
not doing so for sqlite3_prepare_v2. I will try to follow it up upstream,
but may not be able to do so soon as I will out for 2 weeks.

Either way, what we are testing for is not a very common scenario: the 
normal scenario of schema reload/recompilation *is* handled properly.
I've removed the test in the updated patches, we should make a call
whether to re-include it with renaming to 
testTableAddedVisibleInOtherConnection()

Regards,
ashish

-------------- next part --------------
A non-text attachment was scrubbed...
Name: r25_sqlite_prepare_v2.patch
Type: application/octet-stream
Size: 10862 bytes
Desc: r25_sqlite_prepare_v2.patch
URL: <https://stat.ethz.ch/pipermail/r-sig-db/attachments/20070720/de6cb885/attachment.obj>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: trunk_sqlite_prepare_v2.patch
Type: application/octet-stream
Size: 12949 bytes
Desc: trunk_sqlite_prepare_v2.patch
URL: <https://stat.ethz.ch/pipermail/r-sig-db/attachments/20070720/de6cb885/attachment-0001.obj>