On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
"Andrew Finkenstadt" <[EMAIL PROTECTED]> wrote: > I'm exploring what it would take to support more than 10 attached databases > within one SQLite connection object. It appears that the change will be > rather simple: > > ATTACH_MAX can be made as high as 30 without further issues, given the > writeMask and cookieMask field's bit width being 32 bits, with two bits > reserved for the main and temporary data stores. > > If I wanted to increase ATTACH_MAX even farther, going up through 62 would > be relatively easy, assuming 64-bit support in the compiler (as determined > by sqlite_uint64), changing the datatypes for writeMask and cookieMask in > structure Parse, and verifying the mask computations continue to work, and > running all the tests on the desired platforms. Statements like "1<<iDb" > might need to be changed to read "1ULL << iDb" (1 unsigned long long) for > some sorts of excessive warnings, although I haven't yet checked. Are there > any other issues known by changing ATTACH_MAX to a number like 62? I > imagine that the Parse structure size changing might be an issue for > pre-parsed statements... > > The code for attaching databases (attachFunc()) appears to be agnostic when > it comes to these limits. These are the only issues I am aware of. I do not understand the concern about Parse structure size changing....
I did not research how prepared statements have their vdbe opcodes serialized or stored, and whether those opcodes depend on the size of the Parse structure, whose size would be changing by bumping the writeMask or cookieMask fields from u32 to u64; and if I needed to bump MAX_ATTACH even higher, an entirely different way of tracking the cookieMask and writeMask. If they don't, then that's a moot point.
