| Goals of the sql and sql/driver packages: | |
| * Provide a generic database API for a variety of SQL or SQL-like | |
| databases. There currently exist Go libraries for SQLite, MySQL, | |
| and Postgres, but all with a very different feel, and often | |
| a non-Go-like feel. | |
| * Feel like Go. | |
| * Care mostly about the common cases. Common SQL should be portable. | |
| SQL edge cases or db-specific extensions can be detected and | |
| conditionally used by the application. It is a non-goal to care | |
| about every particular db's extension or quirk. | |
| * Separate out the basic implementation of a database driver | |
| (implementing the sql/driver interfaces) vs the implementation | |
| of all the user-level types and convenience methods. | |
| In a nutshell: | |
| User Code ---> sql package (concrete types) ---> sql/driver (interfaces) | |
| Database Driver -> sql (to register) + sql/driver (implement interfaces) | |
| * Make type casting/conversions consistent between all drivers. To | |
| achieve this, most of the conversions are done in the sql package, | |
| not in each driver. The drivers then only have to deal with a | |
| smaller set of types. | |
| * Be flexible with type conversions, but be paranoid about silent | |
| truncation or other loss of precision. | |
| * Handle concurrency well. Users shouldn't need to care about the | |
| database's per-connection thread safety issues (or lack thereof), | |
| and shouldn't have to maintain their own free pools of connections. | |
| The 'sql' package should deal with that bookkeeping as needed. Given | |
| an *sql.DB, it should be possible to share that instance between | |
| multiple goroutines, without any extra synchronization. | |
| * Push complexity, where necessary, down into the sql+driver packages, | |
| rather than exposing it to users. Said otherwise, the sql package | |
| should expose an ideal database that's not finicky about how it's | |
| accessed, even if that's not true. | |
| * Provide optional interfaces in sql/driver for drivers to implement | |
| for special cases or fastpaths. But the only party that knows about | |
| those is the sql package. To user code, some stuff just might start | |
| working or start working slightly faster. | |