From 4d441ce5858b482aa4caccc77ba582b66038c009 Mon Sep 17 00:00:00 2001 From: "Madd.is" Date: Tue, 18 Apr 2017 19:17:15 +0200 Subject: [PATCH] fix header formatting --- Parameterized-queries-and-Prepared-Statements.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Parameterized-queries-and-Prepared-Statements.md b/Parameterized-queries-and-Prepared-Statements.md index 37ad497..52a1bcd 100644 --- a/Parameterized-queries-and-Prepared-Statements.md +++ b/Parameterized-queries-and-Prepared-Statements.md @@ -4,12 +4,12 @@ - parameterized, e.g. `query( "select name from emp where emp_id=$1", [123] )` - prepared, e.g. `query( {name:"emp_name", text:"select name from emp where emp_id=$1", values:[123]} )` -##Text Queries## +## Text Queries ## Plain text queries, for a single query instance, are faster and the most flexible. They are also the most insecure, providing no barrier to SQL injection attacks. -##Parameterized Queries## +## Parameterized Queries ## A parameterized query allows you "pass arguments" to a query, providing a barrier to SQL injection attacks. @@ -88,7 +88,7 @@ error: cannot insert multiple commands into a prepared statement A workaround is to do 2 separate queries and using whatever type of async flow control to dispatch them. -##Prepared Statements## +## Prepared Statements ## A prepared statement lets postgres parse, analyze, and rewrite a statement just once instead of every time it is used. Postgres may also plan the query just once, if it estimates that there would be little benefit from constructing parameter-specific plans. @@ -115,13 +115,13 @@ The following will help track: Accumulated prepared statements can build cruft if not deallocated, but premature deallocation forces postgres to replan the statement if reissued, losing the speed benefits. -###Using Prepared Statements### +### Using Prepared Statements ### pg tracks which statements have been prepared for a session - you do not need one query to prepare and a second one to execute: the same query, if passed name, text and values, can be used each time you wish to execute the query - pg will prepare the query first only if it needs to. -####`values` are required +#### `values` are required It is not possible to simply create a prepared statement without executing it. e.g. the following will throw an error: ```javascript client.query( { @@ -134,7 +134,7 @@ The error is Of course, `values` are not required if there are no parameters in the query. But even in those instances, the query is executed when `client.query()` is invoked. -####Re-using prepared statements +#### Re-using prepared statements Since caching is per-session, sometimes it is not possible to be sure that a given prepared statement exists in the cache. If all calls are made within the same `pg.connect` block, the statement will be cached because all calls use the same pg session. However, in practical use (e.g. with Express), you could have a pool of pg connections being used by middleware serving hundreds of HTTP requests. The fail-safe way to use prepared statements is to always supply both the `text` and the `name`. When a statement named `name` is found to be cached, `text` is ignored and the cached statement is used. If `name` is not found in the cache, a new prepared statement is created using the `text` supplied. (as discussed in [this issue](https://github.com/brianc/node-postgres/issues/903))