Be explicit about working on the system database.

When using a non-standard pg_system_user psql assumes you want
to access a database with the same name as the user, unless you
specify explicitly. This database should normally be calles
'postgres', but in case someone has a really weird setup I made
it configurable.
v3.0.1
Changed to release_roles :all as roles that needs database.yml

Other roles besides :app need to be able to access the database. For
example, a dedicated db node that runs its own migrations but is not have
the :app role needs the Ruby code and database.yml. In migrations.rake of
capistrano-rails, the migrations can be run on a role specified by the
migration_role.

This commit is to ensure that all release_roles have a copy of database.yml
on setup, in order that they can connect to the database.
Merge pull request #6 from capistrano-plugins/database_client_roles

Changed to release_roles :all as roles that needs database.yml
Ensure database.yml on newly created clients has correct credentials. fix #5

This commit changes the was database.yml is created. Previously, a randomly
generated password would be created on database set up, but also when a client
does not have the database.yml file. If a new client if created after the db,
it gets a database.yml file with a newly generated random - and incorrect -
password.

In this commit, when the db and db-user are first created, an archetype
database.yml file is created on the primary db role with the credentials
for the db. This is subsequently copied on every setup to all clients, so
newly created clients now also get the right credentials for connecting
to the db.
Merge pull request #7 from capistrano-plugins/issue_5

Ensure database.yml on newly created clients has correct credentials. fixes #5
Added optional addition of hstore extension to db
Merge pull request #8 from capistrano-plugins/hstore

Added optional addition of hstore extension to db
Take `rails_env` option into consideration

This change splits the direct connection between a `stage` option and DB
environment.

A user might have a stage file example: `config/deploy/staging_new.rb`
With this, `stage` variable is set to `staging_new` which makes no
sense.

With this update a user can:
- set the stage with `rails_env` option. This is convenient and "just
  works" if capistrano-rails gem is used.
- set the DB env explicitly with `pg_env` option. This one should not be
  necessary though.

Lastly, this change is "backwards compatible", meaning - without extra
options everything will work as until now.
Readme link to capistrano-plugins github org
Merge pull request #11 from capistrano-plugins/more_plugins

Readme link to capistrano-plugins github org
Merge pull request #9 from capistrano-plugins/rails_env

Take `rails_env` option into consideration
Upgrade task for gem version 4.0
Merge pull request #13 from capistrano-plugins/upgrade_task

Upgrade task for gem version 4.0
Update readme
Merge pull request #12 from capistrano-plugins/update_docs

Update readme & changelog for gem version 4.0
v4.0.0
Automatic pg_host
Merge pull request #14 from capistrano-plugins/automatic_pg_host

Automatically set proper pg_host
v4.1.0