database/sql: think about a std error / informational messages #19797
Comments
|
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. |
|
CL https://golang.org/cl/39355 mentions this issue. |
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 ). Updates golang/go#19797
|
CL https://golang.org/cl/38533 mentions this issue. |
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. Fixes #13567 Fixes #18079 Updates #18417 Updates #17834 Updates #16235 Updates #13067 Updates #19797 Change-Id: I89088bd9cca4596a48bba37bfd20d987453ef237 Reviewed-on: https://go-review.googlesource.com/38533 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
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: