Many databases support returning multiple errors, with each error containing a line number, text, and numeric code. I want to explore what it would take to define a standard error interface that could be used to unpack this information. A concrete use case is to 1000 line SQL block that errored, then show just the context of the portions where it errored. A concrete use case for getting the error code is when a user raises a user error, it is often useful to distinguish this from a SQL syntax error. You may wish to abort a query early within the SQL text and only in that condition expose the user to the underlying message, but in the case of generic SQL errors, hide or retry them.
In a similar way, Postgresql, MS SQL, and Oracle all support the concept of streaming messages while the query is running. This is less of an issue, but still might be useful. Fewer concrete uses for messages in SQL.
The text was updated successfully, but these errors were encountered:
I don't really have a concrete use for Messages. I'm going to put that thought on hold.
I'm going to proceed looking into this and determine if a common sql error interface makes sense. If I think it does I'll define it initially outside the std lib. If it gets use I'll propose adding it in.
Here's a package I wrote to solve a similar problem, which was that the native error messages returned by Postgres really weren't appropriate for exposing to end users. https://github.com/Shyp/go-dberror
I also had the library export common error codes, like unique constraint failure, not null violation, etc. It's a problem that those are different on different database engines and I'm not sure how to resolve that.
Drivers ususally hide the details of messages
from the server. Most clients don't care about details
or include complex SQL with multiple statements. Many still
do care about these details. Provide a way to dequeue messages
from the driver.
Relies on go1.9 ( https://golang.org/cl/38533 ).
Previously all arguments were passed through driver.IsValid.
This checked arguments against a few fundamental go types and
prevented others from being passed in as arguments.
The new interface driver.NamedValueChecker may be implemented
by both driver.Stmt and driver.Conn. This allows
this new interface to completely supersede the
driver.ColumnConverter interface as it can be used for
checking arguments known to a prepared statement and
arbitrary query arguments. The NamedValueChecker may be
skipped with driver.ErrSkip after all special cases are
exhausted to use the default argument converter.
In addition if driver.ErrRemoveArgument is returned
the argument will not be passed to the query at all,
useful for passing in driver specific per-query options.
Add a canonical Out argument wrapper to be passed
to OUTPUT parameters. This will unify checks that need to
be written in the NameValueChecker.
The statement number check is also moved to the argument
converter so the NamedValueChecker may remove arguments
passed to the query.
Reviewed-by: Brad Fitzpatrick <email@example.com>
Run-TryBot: Brad Fitzpatrick <firstname.lastname@example.org>
TryBot-Result: Gobot Gobot <email@example.com>