Fix pg-native prepare example output and doc typos

README.md

@@ -90,7 +90,7 @@ If your change involves breaking backwards compatibility please please point tha
 1. Clone the repo
 2. Ensure you have installed libpq-dev in your system (the native bindings are built in the test process)
 3. From your workspace root run `yarn` and then `yarn lerna bootstrap`
-4. Ensure you have a PostgreSQL instance running with SSL enabled and an empty database for tests. _note: you can skip the tests requring SSL by setting the environment variable `PGTESTNOSSL=1` if you're not changing any SSL related code_.
+4. Ensure you have a PostgreSQL instance running with SSL enabled and an empty database for tests. _note: you can skip the tests requiring SSL by setting the environment variable `PGTESTNOSSL=1` if you're not changing any SSL related code_.
 5. Ensure you have the proper environment variables configured for connecting to your postgres instance. Using the standard `PG*` environment variables like `PGUSER` and `PGPASSWORD` etc...
 6. Run `yarn test` to run all the tests.
 

docs/pages/guides/upgrading.md

@@ -5,7 +5,7 @@ slug: /guides/upgrading
 
 ## node version support
 
-I have maintained legacy apps in production for many years. I get it...upgrading node and your entire dependency tree is rough, but so is missing out on critical fixes.  I've taken pride over the years in not introducing breaking changes without a need because I've spent too much of my own time in my own apps upgrading a semver major version of a library with many breaking changes.  That being said: node-postgres only _officially_ supports node versions which are still under the [LTS lifetime](https://nodejs.org/en/about/previous-releases). The [CI matrix](https://github.com/brianc/node-postgres/blob/master/.github/workflows/ci.yml#L39) is the most official and enforced compatiblity matrix; however, I may drop support for node versions outside of node's LTS lifetime at any time, with any semver minor release, if it is required to land new features or bug fixes on supported versions of node.  I recommend in general to use a lockfile, and, if you're on an older version of node nearing EOL use absolutely pinned versions for as many of your modules as you can, including this one.
+I have maintained legacy apps in production for many years. I get it...upgrading node and your entire dependency tree is rough, but so is missing out on critical fixes.  I've taken pride over the years in not introducing breaking changes without a need because I've spent too much of my own time in my own apps upgrading a semver major version of a library with many breaking changes.  That being said: node-postgres only _officially_ supports node versions which are still under the [LTS lifetime](https://nodejs.org/en/about/previous-releases). The [CI matrix](https://github.com/brianc/node-postgres/blob/master/.github/workflows/ci.yml#L39) is the most official and enforced compatibility matrix; however, I may drop support for node versions outside of node's LTS lifetime at any time, with any semver minor release, if it is required to land new features or bug fixes on supported versions of node.  I recommend in general to use a lockfile, and, if you're on an older version of node nearing EOL use absolutely pinned versions for as many of your modules as you can, including this one.
 
 # Upgrading to 8.0
 

packages/pg-native/README.md

@@ -78,7 +78,7 @@ client.connect(function(err) {
 
 ### sync
 
-Because `pg-native` is bound to [libpq](https://github.com/brianc/node-libpq) it is able to provide _sync_ operations for both connecting and queries. This is a bad idea in _non-blocking systems_ like web servers, but is exteremly convienent in scripts and bootstrapping applications - much the same way `fs.readFileSync` comes in handy.
+Because `pg-native` is bound to [libpq](https://github.com/brianc/node-libpq) it is able to provide _sync_ operations for both connecting and queries. This is a bad idea in _non-blocking systems_ like web servers, but is extremely convenient in scripts and bootstrapping applications - much the same way `fs.readFileSync` comes in handy.
 
 ```js
 const Client = require('pg-native')
@@ -207,7 +207,7 @@ client.connect(function(err) {
     client.execute('i_like_beans', ['Brak'], function(err, rows) {
       if(err) throw err
 
-      console.log(rows) // [{ "i_like_beans": "Brak" }]
+      console.log(rows) // [{ "beans": "Brak" }]
       client.end()
     })
   })

packages/pg-pool/README.md

@@ -343,7 +343,7 @@ To run tests clone the repo, `npm i` in the working dir, and then run `npm test`
 
 ## contributions
 
-I love contributions. Please make sure they have tests, and submit a PR. If you're not sure if the issue is worth it or will be accepted it never hurts to open an issue to begin the conversation. If you're interested in keeping up with node-postgres releated stuff, you can follow me on twitter at [@briancarlson](https://twitter.com/briancarlson) - I generally announce any noteworthy updates there.
+I love contributions. Please make sure they have tests, and submit a PR. If you're not sure if the issue is worth it or will be accepted it never hurts to open an issue to begin the conversation. If you're interested in keeping up with node-postgres related stuff, you can follow me on twitter at [@briancarlson](https://twitter.com/briancarlson) - I generally announce any noteworthy updates there.
 
 ## license
 

packages/pg/README.md

@@ -67,7 +67,7 @@ I will **happily** accept your pull request if it:
 - looks reasonable
 - does not break backwards compatibility
 
-If your change involves breaking backwards compatibility please please point that out in the pull request & we can discuss & plan when and how to release it and what type of documentation or communicate it will require.
+If your change involves breaking backwards compatibility please please point that out in the pull request & we can discuss & plan when and how to release it and what type of documentation or communication it will require.
 
 ## Troubleshooting and FAQ