Merge 5ca4e7e into a001ea7

.editorconfig

@@ -0,0 +1,9 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true

.npmignore

@@ -4,5 +4,4 @@ coverage/
 *.tgz
 .nyc_output/
 docs/
-CHANGELOG.md
-README.md
+.editorconfig

.travis.yml

@@ -8,8 +8,9 @@ language: node_js
 node_js:
   - "12"
   - "10"
-  - "8"  
+  - "8"
 before_script:
   - psql -c 'create database pgboss' -U postgres
+  - psql -c 'create extension pgcrypto' -d pgboss -U postgres
 script:
   - npm run forcover

README.md

@@ -14,11 +14,11 @@ async function readme() {
   boss.on('error', error => console.error(error));
 
   await boss.start();
-  
+
   const queue = 'some-queue';
 
   let jobId = await boss.publish(queue, { param1: 'foo' })
-  
+
   console.log(`created job in queue ${queue}: ${jobId}`);
 
   await boss.subscribe(queue, someAsyncJobHandler);
@@ -27,16 +27,16 @@ async function readme() {
 async function someAsyncJobHandler(job) {
   console.log(`job ${job.id} received with data:`);
   console.log(JSON.stringify(job.data));
-    
+
   await doSomethingAsyncWithThis(job.data);
 }
 ```
 
-pg-boss is a job queue built in Node.js on top of PostgreSQL in order to provide background job processing and reliable asynchronous execution to Node.js applications.
+pg-boss is a job queue built in Node.js on top of PostgreSQL in order to provide background processing and reliable asynchronous execution to Node.js applications.
 
 Why would you consider using this queue over others? pg-boss is actually a light abstraction over features added in PostgreSQL 9.5
 (specifically [SKIP LOCKED](http://blog.2ndquadrant.com/what-is-select-skip-locked-for-in-postgresql-9-5) and upserts)
-which significantly enhanced its ability to act as a reliable, distributed message queue. I wrote this to remove a dependency on Redis (via the kue package), consolidating systems I have to support in production as well as upgrading to guaranteed message processing (hint: [Redis persistence docs](https://redis.io/topics/persistence#ok-so-what-should-i-use)). 
+which significantly enhanced its ability to act as a reliable, distributed message queue. I wrote this to remove a dependency on Redis (via the kue package), consolidating systems I have to support in production as well as upgrading to guaranteed message processing (hint: [Redis persistence docs](https://redis.io/topics/persistence#ok-so-what-should-i-use)).
 
 This will likely cater the most to teams already familiar with the simplicity of relational database semantics and operations (querying and backups, for example).
 
@@ -45,12 +45,14 @@ This will likely cater the most to teams already familiar with the simplicity of
 * Delayed jobs
 * Job retries (opt-in exponential backoff)
 * Job throttling (unique jobs, rate limiting and/or debouncing)
-* Job batching for high volume use cases 
+* Job batching for high volume use cases
 * Backpressure-compatible subscriptions
 * Configurable job concurrency
 * Distributed and/or clustered workers
 * Completion subscriptions to support orchestrations/sagas
 * On-demand job fetching and completion for external integrations (such as web APIs)
+* Multi-master capable using tools such as Kubernetes ReplicaSets
+* Direct table access for bulk loading via COPY or other advanced usage
 * Automatic provisioning of required storage into a dedicated schema
 * Automatic monitoring for expired jobs
 * Automatic archiving for completed jobs