For anyone who has the same questions I had, I've found most of the
answers.
PS. Excellent internal documentation of the VDBE (though a bit out-of-
date)! It made it really easy to navigate the source.
On Feb 12, 2007, at 1:51 PM, Wesley W. Terpstra wrote:
What is the defined behaviour of
The basis of our business has been writing compilers and run time
packages to integrate legacy and newer software. We discovered that
basic computer science provides the answers and looking beyond the
paradigm of the legacy language or system is essential if a complexity
chain reaction is to
On Feb 12, 2007, at 7:32 PM, John Stanton wrote:
I suggest that you also look carefully at the manifest typing
implemented in Sqlite. If your language is strongly typed you will
have some design issues to address.
I am aware of this issue and already have a solution. It's part of
why I
I wasn't suggesting that you use sqlite3_exec. On the contrary I would
counsel you not to. I just suggested that you look to see how it
implements callbacks and that you implement a callback to handle each
row. Then the logic of your interface is elegant.
If you are creating a language
Wesley W. Terpstra wrote:
val Iterator1a = SQL.execute Query1 ("parameter1" & 2)
val Iterator1b = SQL.execute Query1 ("foobar" & 3)
val Iterator2 = SQL.execute Query2 4
case Iterator1a () of
NONE => print "End of this table"
| SOME (x & y) => print ("Got a row: " ^ x ^ ", " ^ Int.toString
On Feb 12, 2007, at 3:22 PM, John Stanton wrote:
Look at how Sqlite implements callbacks in sqlite3_exec to discover
a way to implement your language.
I had already looked at it. I will be using the prepare_v2/bind/step/
reset/.../finalize interface instead. The exec interface is too
Wesley W. Terpstra wrote:
On Feb 12, 2007, at 1:21 AM, John Stanton wrote:
Prepared queries are actually the query compiled into the
metalanguage, VDBE. You can have many statements in one transaction,
and each of those statements can be reusing a VDBE virtual machine
instance with a
On Feb 12, 2007, at 1:21 AM, John Stanton wrote:
Prepared queries are actually the query compiled into the
metalanguage, VDBE. You can have many statements in one
transaction, and each of those statements can be reusing a VDBE
virtual machine instance with a current set of data bound to
Prepared queries are actually the query compiled into the metalanguage,
VDBE. You can have many statements in one transaction, and each of
those statements can be reusing a VDBE virtual machine instance with a
current set of data bound to it.
When you reset the compiled statement you make it
Thanks for your answers!
On Feb 12, 2007, at 1:58 AM, [EMAIL PROTECTED] wrote:
"Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote:
Suppose you have two prepared queries: q1 and q2. I currently believe
that it is an error to execute: step q1, step q2, step q1.
No. Queries can be interleaved this
"Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote:
>
> Suppose you have two prepared queries: q1 and q2. I currently believe
> that it is an error to execute: step q1, step q2, step q1.
No. Queries can be interleaved this way.
>
> In fact, I believe that after step q1, you must either call
Good evening.
I've been working on an SQLite3 binding for Standard ML (SML)
targeting the MLton compiler. I've read all the material on the C API
I've found, but I have some questions about the VM prepare/step
methods. Specifically, I am confused about the lifetime of non-
finalized queries. It
12 matches
Mail list logo
