Prepared Statements (with Parameterized Queries) are the best and most secure way to protect against SQL Injections.
In some reported situations, prepared statements could harm performance of the web application. Therefore, if for any reason you need to stop using this type of database queries, we strongly suggest to read Input Validation and Output Encoding sections.
Go works differently from usual prepared statements on other languages - you don't prepare a statement on a connection. You prepare it on the DB.
- The developer prepares the statement (
Stmt) on a connection in the pool
Stmtobject remembers which connection was used
- When the application executes the
Stmt, it tries to use that connection. If it's not available it will try to find another connection in the pool
This type of flow could cause high-concurrency usage of the database and creates lots of prepared statements. So, it's important to keep this information in mind.
Here's an example of a prepared statement with parameterized queries:
customerName := r.URL.Query().Get("name") db.Exec("UPDATE creditcards SET name=? WHERE customerId=?", customerName, 233, 90)
Sometimes a prepared statement is not what you want. There might be several reasons for this:
The database doesn’t support prepared statements. When using the MySQL driver, for example, you can connect to MemSQL and Sphinx, because they support the MySQL wire protocol. But they don’t support the "binary" protocol that includes prepared statements, so they can fail in confusing ways.
The statements aren’t reused enough to make them worthwhile, and security issues are handled in another layer of our application stack (See: Input Validation and Output Encoding), so performance as seen above is undesired.