> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 07, 2006 6:18 AM > To: sqlite-users@sqlite.org > Subject: [sqlite] Q about new SQLite API > > I'm working on a new API routine for SQLite and I have > questions for the community. [snip] > QUESTION 1: sqlite3_prepare_v2 is the merely the working name > for the new function. What should the official name be?
I prefer a prepare_ex() or something with the word "prepare" in it, because: 1. It will appear next to the original prepare() in the docs alphabetically so your eyes will be more inclined to fall on it 2. People will immediately think "oh, its an extension to the prepare() call" > QUESTION 2: Are there any other API warts that need to be > worked around that can be fixed by this same change? This one doesn't really fit into this category, but I'll spit it out anyway: I've been trying to figure out a way to mitigate starvation issues in multi-threaded scenarios. One idea was to latch into the busy hook, commit hook and rollback hook, but they don't currently tell me which database of any attached databases the hooks are being raised against. To be effective, I'd also need an additional hook when a transaction begins on a specific database, too. :) > QUESTION 3: Suppose there is a schema change and the SQL > statement is automatically reprepared. But the schema change > is such that the SQL is no longer valid. (Perhaps one of the > tables mentioned in a SELECT statement was dropped.) What > error code should sqlite3_step() return in that case? Pass back whatever error you get when your internal code attempts to recompile the statement and fails. Robert ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
