Change SIP to reflect decision about query vs execute

Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>

docs/content/sips/013-sqlite.md

@@ -65,11 +65,8 @@ variant error {
 // `error::no-such-database` will be raised if the `name` is not recognized.
 open: func(name: string) -> expected<connection, error>
 
-// Execute a statement
-execute: func(conn: connection, statement: string, parameters: list<value>) -> expected<unit, error>
-
-// Query data
-query: func(conn: connection, query: string, parameters: list<value>) -> expected<query-result, error>
+// Execute a statement returning back data if there is any
+execute: func(conn: connection, statement: string, parameters: list<value>) -> expected<query-result, error>
 
 // Close the specified `connection`.
 close: func(conn: connection)
@@ -99,12 +96,9 @@ variant value {
 
 *Note: the pseudo-resource design was inspired by the interface of similar functions in [WASI preview 2](https://github.com/bytecodealliance/preview2-prototyping/blob/d56b8977a2b700432d1f7f84656d542f1d8854b0/wit/wasi.wit#L772-L794).*
 
-#### Interface open questions
+The interface only contains an `execute` function. Earlier iterations also included a `query` function. However, `query` and `execute` served very similar roles and had extremely similar implementations. Since adding functions is much easier than taking them away, we have decided to only have an `execute` function to begin with. This `execute` function executes any statement whether it is a query or some sort of database management statement.
 
-**TODO**: answer these questions
-* `row-result` can be very large. Should we provide some paging mechanism or a different API that allows for reading subsets of the returned data?
-  * Crossing the wit boundary could potentially be expensive if the results are large enough. Giving the user control of how they read that data could be helpful.
-* Is there really a need for query *and* execute functions since at the end of the day, they are basically equivalent?
+In the future, we may want to bring back a `query` function that allows the user to "page" through their results (instead of receiving all results in a single - potentially very large - collection). This will avoid some of the performance constraints of the current interface where large `query-result`s could lead to memory issues in constrained environments.
 
 #### Database migrations