heroku / heroku-pg

this code is now in https://github.com/heroku/cli

Heroku Postgres CLI Plugin

Publishing

To publish new versions, see the data plugin documentation.

heroku-pg's Issues

Raises `Parameter "url" must be a string, not undefined` when the default db (`DATABASE_URL`) is an attached addon

$ heroku pg:locks -a keiko-sushi
 ▸    Parameter "url" must be a string, not undefined

$ heroku addons -a keiko-sushi
...
 heroku-postgresql (postgresql-convex-3794)           hobby-basic  (billed to keiko-cedar10 app)
 ├─ as DATABASE
 ├─ as HEROKU_POSTGRESQL_ONYX
 ├─ as MAIN_DB
 └─ as HEROKU_POSTGRESQL_BLACK on keiko-cedar10 app

This is coming from here, because config[addon.config_vars[0]] is undefined. It's undefined because addon.config_vars[0] is HEROKU_POSTGRESQL_BLACK_URL, which I don't have it in keiko-sushi app (I only have it with keiko-cedar10 app). addon.config_vars is being HEROKU_POSTGRESQL_BLACK_URL because that's what owning-app has.

Likely need to change this part?

Heroku pg:copy can get caught in an error state, infinitely printing "▸ not found"

From @Taytay (see heroku/cli#545 )

---

We regularly create and copy Hobby DBs as part of our deploy process. Occasionally, one of these processes will get hung on a pg:copy command. Here's the output from the one I just killed:

00:01:29.050 Creating heroku-postgresql:standard-0 on <OUR_APP>... $50/month
00:01:29.050 The database should be available in 3-5 minutes.
00:01:29.050 ! CAUTION: The database will be empty. If upgrading, you can transfer
00:01:29.050 !          data from another database with pg:copy.
00:01:29.050 Use `heroku pg:wait` to track status.
00:01:29.051 Waiting for postgresql-convex-40295...
00:03:23.043 Creating postgresql-convex-40295... done
00:03:23.044 Created postgresql-convex-40295 as DATABASE_URL
00:03:23.630 Attaching HEROKU_POSTGRESQL_CYAN from <OUR_APP> to <OUR_APP> as HEROKU_POSTGRESQL_CYAN... done
00:03:24.657 Status: available
Status: available
00:03:24.657 Transferring <OLD_APP>:DATABASE to <OUR_APP>:DATABASE...
00:03:43.815 Progress: 0MB/692MB
Progress: 5MB/692MB
Progress: 14MB/692MB
00:03:43.816  ▸    not found
00:03:49.260 
00:03:49.260  ▸    not found
00:03:55.019 
00:03:55.019  ▸    not found
00:04:00.792 
00:04:00.792  ▸    not found
00:04:06.565 
00:04:06.565  ▸    not found
00:04:12.296 
00:04:12.297  ▸    not found
00:04:18.152 
00:04:18.152  ▸    not found
00:04:23.998 
00:04:23.999  ▸    not found
00:04:29.787 
00:04:29.787  ▸    not found
00:04:35.618 
00:04:35.618  ▸    not found
00:04:41.433 
00:04:41.433  ▸    not found
00:04:47.225 
00:04:47.225  ▸    not found
00:04:53.029 
00:04:53.030  ▸    not found
00:04:58.804 
00:04:58.804  ▸    not found
00:05:04.629 
00:05:04.630  ▸    not found

It goes on like that for another 16 hours, so I think it's safe to say it's dead. :)
The copy command looks like this:

heroku pg:copy DATABASE $NEW_DB_ATTACHMENT_NAME --app $HEROKU_APP_NAME --confirm $HEROKU_APP_NAME

In short, we're not doing anything odd. I think that the new DB is disappearing out from under the copy command somehow, and after that, it doesn't know how to recover.

Can complain about ambiguity where there is none #2

This is similar to but distinct from #10

maciek@mothra:~$ heroku pg:info laughing-calmly-2056 --app heroku-redis
Two-factor code: ********************************************
 ▸    Ambiguous identifier; multiple matching attachments found: DATABASE, HEROKU_POSTGRESQL_NAVY.

heroku pg:psql -c 'select pg_sleep(100)' will fail in the middle due to 20s timeout

https://github.com/heroku/heroku-pg/blob/master/lib/psql.js#L19

Also, seems like you can't really change this timeout, and I'm not really sure where 20s is coming from. Well, maybe for bastion? but still...

allow connection to local DB through Unix socket

I don't see that there is currently any way to connect to a database through a Unix socket with heroku pg:pull.

The PostgreSQL command line tools connect using a socket if the host part is empty or starts with a slash. But this command changes the host to localhost if it's empty, and the host portion of a URI can only contain a slash if it's percent-encoded, but url.parse() treats that as part of the path name.

See https://www.postgresql.org/docs/9.6/static/libpq-connect.html#LIBPQ-CONNSTRING for reference.

pg:backups public-url is not BC

The old Ruby implementation had a -q option, which does not work anymore after the update switching to this repo command, breaking my script.

As the new command seems to have the behavior of the old quiet mode (i.e. outputting only the URL), I can update easily, but it would be a good idea to support the option in the BC layer.

pg:pull does not work on windows

pg:pull currently relies on env which is not available on Windows. We could drop our dependence on env by passing URLs directly to pg_dump and pg_restore, but we need to fix the semantically dubious skipDFlag argument here.

Change copy for capture your first backup

@uhoh-itsmaciek and @idan to provide details

Validate Postgres 10 compatibility

See https://github.com/heroku/herokudata/issues/1122

pg:wait will fail even if the requested operation is still continuing

I believe pg:wait should retry several times before doing a hard exit here:

https://github.com/heroku/heroku-pg/blob/master/commands/wait.js#L42

I've recently had an issue where pg:wait failed while my restore continued due to an intermittent network connection (https://help.heroku.com/tickets/453842). This is problematic when you are trying to script restores.

Can this have some sort of retry logic in it so that it only hard crashes after failing multiple times?

pg:backups:schedule is passing the wrong schedule_name

It is passing the addon name (e.g. postgresql-awesome-1234) with current implementation:

heroku-pg/commands/backups/schedule.js

Line 41 in 53abb29

schedule.schedule_name = db.name

It was passing something like DATABASE_URL previously:

https://github.com/heroku/heroku/blob/d7e9718079b9936ffd264529bdd03a6734fd64cc/lib/heroku/command/pg_backups.rb#L576-L588

This is causing the problem that the newly created schedules will be deleted by us automatically, because we don't support such schedule_name.

canceling heroku pg:backups:restore command will hide the cursor in console

how to repro:

1. run heroku pg:backups:restore b001 DATABASE_URL -a myapp -c myapp
2. it says this log message: https://github.com/heroku/heroku-pg/blob/master/commands/backups/restore.js#L62-L66
3. do Ctrl+C
4. the canceling to see the progress part is going well, but the cursor is gone

running things like reset works but it is pretty annoying, and I don't really know why it is happening.

pg:copy prints the database port twice

When using pg:copy I noticed the output printed the database port two times:

ᐅ heroku pg:copy postgres://user:pass@server-hostname:5432/db-name RESTORED_DATABASE_URL --app my-app --confirm my-app
Starting copy of database db-name on server-hostname:5432:5432 to RESTORED_DATABASE... done
Copying... done

does not exit cleanly if pg:psql postgres connection dies

Steps to repro:

1. Run heroku pg:psql
2. In a separate session, find the pid of the first session and run pg_terminate_backend (I think pg:killall would also work)
3. Try to exit the original psql session with \q. You'll get the following error:

shogun-maciek::DATABASE=> \q
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at exports._errnoException (util.js:1007:11)
    at TCP.onread (net.js:563:26)

Warn on pg:psql with unattached credential

If you try to run heroku pg:psql --credential unattached-cred (where unattached-cred exists but is not attached anywhere), you'll get the opaque error

Couldn't find that addon.

Which is not entirely correct (the addon may have been found, but the attachment using the specified credential was not). We should give a better error in this case.

Fetcher throws incorrect error with zero-config_vars attachments

During the provisioning, there is a timing that there's an attachment but there's not config_vars.
Under that condition, https://github.com/heroku/heroku-pg/blob/master/lib/fetcher.js#L61 will throw the error https://github.com/heroku/heroku-pg/blob/master/lib/util.js#L12 .

This is especially bad for staging environment where we actually need to reach to that point (for prod, usually resolving addon finishes before hitting there).

pg:copy Cannot read property 'started_at' of undefined

-> % heroku pg:copy rbriggs-pg-copy-source::DATABASE_URL DATABASE_URL -a rbriggs-pg-copy-dest 
 ▸    WARNING: Destructive action
 ▸    This command will remove all data from DATABASE
 ▸    Data from DATABASE will then be transferred to DATABASE
 ▸    To proceed, type rbriggs-pg-copy-dest or re-run this command with --confirm rbriggs-pg-copy-dest

> rbriggs-pg-copy-dest
Starting copy of DATABASE to DATABASE... done
Copying... !
 ▸    Cannot read property 'started_at' of undefined
TypeError: Cannot read property 'started_at' of undefined
    at /Users/rbriggs/src/github.com/heroku/heroku-pg/lib/pgbackups.js:95:27
    at throw (native)
    at onRejected (/Users/rbriggs/src/github.com/heroku/heroku-pg/node_modules/co/index.js:81:24)
    at process._tickCallback (internal/process/next_tick.js:103:7)

Port passed to pg:pull is ignored

I raised the same issue here heroku/cli#357 but I guess this is where the issue actually is.

Since Friday whenever I run

PGPORT=5433 heroku pg:pull ...

I get

createdb: could not connect to database template1: could not connect to server: Connection refused
	Is the server running on host "localhost" (::1) and accepting
	TCP/IP connections on port 5432?
could not connect to server: Connection refused
	Is the server running on host "localhost" (127.0.0.1) and accepting
	TCP/IP connections on port 5432?

I have postgres running on port 5433 not 5432 so obviously the connection is refused.

I also noticed there aren't any tests for non-standard ports in test/commands/pull.js

pg:pull expecting ssl connection?

Running heroku-cli/5.6.4-5c98d4f (darwin-amd64) go1.7.4

If I call heroku pg:pull DATABASE_URL db/path --app app-name I get psql: server does not support SSL, but SSL was required.

I've tried to pass a configuration strings in various forms (URI and key/value pairs) instead of db name but no success.

CLI updates for new PG plans

We're supporting core in allowing users to update to the brand new pg plans.

There's a hard launch date here of Jan 17th.

https://xray.herokai.com/projects/new-postgres-plans-eligible-databases
https://salesforce.quip.com/T9iqAwdCLCsZ

psql history not saved line-by-line

I'm not sure if this is a change or not, but it seems that if you run a set of commands and abort the pg:psql session via ctrl-c, the history isn't saved.

I thought that under the legacy pg:psql that history was saved each time you executed a statement, but I might be wrong.

Ctrl+C in pg:psql exiting

When using pg:psql and pressing Ctrl+C (e.g. to cancel a query), the entire psql process exits instead of being trapped and cancelling the running statement.

I ran into this before and was told to reinstall the CLI. This worked last time, but this is happening again. I reinstalled the CLI again, but still no luck. I am on heroku-cli/6.6.13-57fc242 (darwin-x64) node-v7.9.0.

pg:diagnose is receiving the wrong format for plan name

pgdiagnose is expecting to receive the plan name like standard-0, instead of heroku-postgresql:standard-0.
This is causing the issue that we don't know the proper plan in pgdiagnose side, and always reporting RED for "Connection Count". The easy fix would be changing heroku-pg and pass the param that pgdiagnose expects.

https://github.com/heroku/pgdiagnose/blob/master/plans.go
https://github.com/heroku/heroku-pg/blob/master/test/commands/diagnose.js#L11

Perviously:

https://github.com/heroku/heroku/blob/master/lib/heroku/helpers/pg_diagnose.rb#L50

Odd error when tethered to verizon mifi

I had a pretty solid mifi connection, so that might be a red herring.

I had terminated a statement, quitting psql and then connected again though I don't think that matters. This essentially aborted while I was entering the command with the SSL SYSCALL error.

This may entirely be the fault of the psql client, which I'm guessing this hands off to.

heroku pg:psql -a core-db thinking-gently-1078
Two-factor code: ********************************************
--> Connecting to thinking-gently-1078
Null display is "[NULL]".
Timing is on.
Expanded display is used automatically.
psql (9.5.5, server 9.4.1)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

ec2-23-21-74-98.compute-1.amazonaws.com u6v3s6a93ehvfm@dnq97qb0zk4124=> select resources.id, count(app_addons.id) from resources, app_addons where SSL SYSCALL error: Connection timed out
Time: 1929852.544 ms
ec2-23-21-74-98.compute-1.amazonaws.com u6v3s6a93ehvfm@dnq97qb0zk4124=> \q     resources.id, count(app_addons.id) from resources, app_addons where^C
ec2-23-21-74-98.compute-1.amazonaws.com u6v3s6a93ehvfm@dnq97qb0zk4124=> 

pg:backups:restore should require an explicit database

Right now it defaults to DATABASE_URL, but there's little reason to do that and it's a bit of a foot gun. We should require the database to be explicitly specified.

Support `--jobs` for `pg:pull` to be used with pg_restore

From pg_restore's man page:

-j number-of-jobs
--jobs=number-of-jobs

Run the most time-consuming parts of pg_restore -- those which load data, create indexes, or create constraints -- using multiple concurrent jobs. This option can dramatically reduce the time to restore a large database to a server running on a multiprocessor machine.

Feature request: show % progress in cli upon heroku pg:copy command issues

pg:promote does not work with attached database

Temporary 404s with renamed databases

Because we contact the Shogun API using add-on names rather than their uuids, for a period of time after a rename, Shogun is unable to find the add-on. Due to related sync issues in Shogun, we have some heuristic error handling where anything that 404s is "not yet provisioned". This means we give a misleading error message:

➜ h addons:rename --app sushi postgresql-shiny-12345 sushi-primary
postgresql-shiny-12345 successfully renamed to sushi-primary.
➜ h pg:info --app sushi
 ▸    sushi-primary is not yet provisioned.
 ▸    Run heroku pg:wait to wait until the db is provisioned.

Changing the client to using uuids to contact Shogun would work around this problem.

/cc @mikelikesbikes

Does not cleanly handle Ctrl+C on long-running queries

It looks like this kills psql (instead of interrupting the query) and leaves the command shell in a bad state. I can't reproduce this on Ubuntu but @fnando reproduced this in OS X. It's not clear whether Windows is affected.

Default database not picked for pg:psql when --credential passed in

maciek@mothra:~$ <<<"select 1" heroku pg:psql -a creds-testing
--> Connecting to postgresql-tetrahedral-77884
Pager usage is off.
Null display is "💩".
 ?column? 
----------
        1
(1 row)

maciek@mothra:~$ <<<"select 1" heroku pg:psql --credential read-only -a creds-testing
 ▸    Couldn't find that addon.
maciek@mothra:~$ <<<"select 1" heroku pg:psql --credential read-only postgresql-tetrahedral-77884 -a creds-testing
--> Connecting to postgresql-tetrahedral-77884
Pager usage is off.
Null display is "💩".
 ?column? 
----------
        1
(1 row)

pg:ps fails with 'column "waiting" does not exist'

i'm running this command against heroku postgres 9.6.x databases. i'm running from OSX, heroku CLI installed via brew.

heroku pg:ps --app rivaliq-usertest
ERROR:  column "waiting" does not exist
LINE 7:  waiting,
         ^
Timing is on.
Expanded display is used automatically.
Null display is "(null)".
Time: 73.484 ms

heroku --version
heroku-cli/6.6.13-57fc242 (darwin-x64) node-v7.9.0

which heroku
/usr/local/bin/heroku

ls -l /usr/local/bin/heroku
lrwxr-xr-x  1 spollack  admin  33 May 18 13:17 /usr/local/bin/heroku -> ../Cellar/heroku/6.6.7/bin/heroku

cat /usr/local/Cellar/heroku/6.6.7/libexec/node_modules/heroku-pg/package.json | grep "version"
  "version": "2.0.26",

I see there was a fix here in heroku-pg to be compatible with pg 9.6.x, but it doesn't seem to be working for me.

Thanks,
Seth

`Couldn't find that add-on.` when there is no default database configured in DATABASE_URL

Expected behavior (and is working well with heroku pg:diagnose, because it's still using Ruby one... I think?):

$ heroku pg:diagnose -a keiko-cedar10
 !    No default database configured in DATABASE_URL. Valid alternatives are: HEROKU_POSTGRESQL_BLACK_URL

Confusing behavior with commands of heroku-pg-extras:

$ heroku pg:locks -a keiko-cedar10
 ▸    Couldn't find that add-on.

Likely it's failing here, where it tries to search the addon DATABASE_URL with heroku-cli-addons and it does say it couldn't find that add-on.
I guess this part of error handling is not imported to heroku-pg? https://github.com/heroku/heroku/blob/master/lib/heroku/helpers/heroku_postgresql.rb#L223-L229

False extension mismatch reported with pg:pull + partially-qualified local database + no ssl

I have a local database, sample, that I am pg:pull-ing into. The local database server doesn't support SSL connections, and the production database has 7 extensions.

If I use heroku pg:pull DATABASE sample, the server's extensions will be correctly CREATE-ed locally, but the CLI will report an extension mismatch:

heroku-cli: Pulling postgresql-removed-999999 ---> sample
pg_dump: reading extensions
pg_dump: identifying extension members
pg_dump: reading schemas
[...]
pg_restore: creating SCHEMA "public"
pg_restore: creating EXTENSION "plpgsql"
pg_restore: creating COMMENT "EXTENSION plpgsql"
pg_restore: creating EXTENSION "fuzzystrmatch"
pg_restore: creating COMMENT "EXTENSION fuzzystrmatch"
pg_restore: creating EXTENSION "hstore"
pg_restore: creating COMMENT "EXTENSION hstore"
pg_restore: creating EXTENSION "pg_stat_statements"
pg_restore: creating COMMENT "EXTENSION pg_stat_statements"
pg_restore: creating EXTENSION "pg_trgm"
pg_restore: creating COMMENT "EXTENSION pg_trgm"
pg_restore: creating EXTENSION "unaccent"
pg_restore: creating COMMENT "EXTENSION unaccent"
pg_restore: creating EXTENSION "uuid-ossp"
pg_restore: creating COMMENT "EXTENSION "uuid-ossp""
[...]
psql: server does not support SSL, but SSL was required
 ▸    WARNING: Extensions in newly created target database differ from existing source database.
 ▸    Target extensions:
 ▸    
 ▸    Source extensions:
 ▸    extname
 ▸    --------------------
 ▸    fuzzystrmatch
 ▸    hstore
 ▸    pg_stat_statements
 ▸    pg_trgm
 ▸    plpgsql
 ▸    unaccent
 ▸    uuid-ossp
 ▸    (7 rows)
 ▸    
 ▸    
 ▸    HINT: You should review output to ensure that any errors
 ▸    ignored are acceptable - entire tables may have been missed, where a dependency
 ▸    could not be resolved. You may need to to install a postgresql-contrib package
 ▸    and retry.
heroku-cli: Pulling complete.

If I fully-qualify my local database's URL with heroku pg:pull DATABASE postgres://localhost/sample, however, it works:

heroku-cli: Pulling postgresql-removed-999999 ---> sample
pg_dump: reading extensions
pg_dump: identifying extension members
pg_dump: reading schemas
[...]
pg_restore: creating SCHEMA "public"
pg_restore: creating EXTENSION "plpgsql"
pg_restore: creating COMMENT "EXTENSION plpgsql"
pg_restore: creating EXTENSION "fuzzystrmatch"
pg_restore: creating COMMENT "EXTENSION fuzzystrmatch"
pg_restore: creating EXTENSION "hstore"
pg_restore: creating COMMENT "EXTENSION hstore"
pg_restore: creating EXTENSION "pg_stat_statements"
pg_restore: creating COMMENT "EXTENSION pg_stat_statements"
pg_restore: creating EXTENSION "pg_trgm"
pg_restore: creating COMMENT "EXTENSION pg_trgm"
pg_restore: creating EXTENSION "unaccent"
pg_restore: creating COMMENT "EXTENSION unaccent"
pg_restore: creating EXTENSION "uuid-ossp"
pg_restore: creating COMMENT "EXTENSION "uuid-ossp""
[...]
heroku-cli: Pulling complete.

Note the line psql: server does not support SSL, but SSL was required in the failing example.

The psql code here is not correctly checking for null hostnames, which imply localhost in Postgres URLs:

heroku-pg/lib/bastion.js

Line 29 in e9e17e6

PGSSLMODE: db.hostname === 'localhost' ? 'prefer' : 'require',

URLs like foo are valid Postgres URLs: foo is equivalent to postgres://localhost/foo (default user, no password, default port, etc)

Uses namespaced attachment in informational messages

maciek@mothra:~/code/herokudata$ heroku pg:upgrade postgresql-polished-66551 -a transferatu-maciek
 ▸    WARNING: Destructive action
 ▸    postgresql-polished-66551 will be upgraded to a newer PostgreSQL version, stop following WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW, and become writable.
 ▸    
 ▸    This cannot be undone.
 ▸    To proceed, type transferatu-maciek or re-run this command with --confirm transferatu-maciek

That is a namespaced attachment; the message should use only un-namespaced attachments.

Support a --template flag in cred creation for parity with DHC

Confusing messaging in credential listing

It's not clear what "waiting for no connections to be revoked" means...

[Feature request] Support -f for the pg:psql command

The -f option of psql allowing to run a sql file in psql is quite handy when having to write a big query, instead of copy-pasting it in an interactive session. But heroku pg:psql does not support it (while it supports -c).

My workaround until now was to retrieve the credentials URL and then use psql directly. However, this does not work for a private plan DB, as this would not go through the bastion SSH tunnel (and yes, I just went reading the source code of this package to understand how pg:psql could connect to the private DB).
It would be great if -f could be supported by heroku pg:psql directly.

Feature : Add some more options to pg:pull through pg_dump

Hello,

A very useful option has been lost when removing taps from the cli : the ability to exclude some table datas based on a table name. I wish it were back. It seems to me possible (not totally sure), looking at the code from pull.js where the dump command is defined as :

let dump = `env${password(source.password)} PGSSLMODE=prefer pg_dump --verbose -F c -Z 0 ${connstring(source, true)}`

Thus a few more options could be passed to add provide more pg_dump features, especially the --exclude-table-data=MYTABLE option.

What about re-adding this ? :) Thanks!

Unresolvable ambiguity when one attachment name substring of other

maciek@mothra:~/code/aux/heroku-kafka-jsplugin$ h pg:info database -a shogun
 ▸    Ambiguous identifier; multiple matching attachments found: DATABASE, DOD_HVAS_DATABASE.

A workaround is to use the add-on haiku name here, but that's not obvious from the error message.

pg:backups:download does not properly clean up terminal on progress updates

pg:pull does not tunnel through bastions

The pg:pull command does not tunnel through bastions when used on a Private database. It instead tries to connect directly to the database instance.

Can complain about ambiguity where there is none

maciek@mothra:~$ heroku pg:psql bronze --app shogun-cedar
 !    Ambiguous identifier; multiple matching attachments found: HEROKU_POSTGRESQL_BRONZE, HEROKU_REDIS_BRONZE.

Clearly I'm not trying to psql into my Redis =)

404 from `/databases/:name` results in misleading error when dbs are attached to another app

--> GET /client/v11/databases/xxxx
--> GET /client/v11/databases/xxxx
<-- 404 Not Found
<-- {"error":"not found"}
 ▸    xxxx is not yet provisioned.
 ▸    Run heroku pg:wait to wait until the db is provisioned.
<-- 404 Not Found
<-- {"error":"not found"}
 ▸    xxxx is not yet provisioned.
 ▸    Run heroku pg:wait to wait until the db is provisioned.

These resources are available but are attached to a separate application.

pg:backups:restore fails with non-helpful message with wrong single quote URL

There was a Windows user who used the "wrong" single quote and ended up seeing an unhelpful error message.

heroku pg:backups:restore ’https://some-s3-url/of-dump-file.dump’ DATABASE -a appname
 ▸    Backup ’https://some-s3-url/of-dump-file.dump’ not found for ⬢ appname

Maybe error messages can be a bit more helpful...?

heroku pg:psql throws the error psql:could not translate host name "ec2.<>.amazonaws.com" to address: Unknown server error.

I am trying to use the heroku postgres database. I have installed PostgresSQL 10 on my windows system. psql command works fine while connecting to the local database. While connecting to heroku postgres,it throws the error saying could not translate host name. This maybe because of the proxy settings.

Commands I have used are
1.psql --host --port 5432 --username --dbname
2.psql "dbname= host= user= password= port=5432"
3.heroku pg:psql postgresql-<>-<> --app

All these commands give the same error Unknown server error.
Is there a way around this or any alternative?
Thanks in advance!

pg:push refusing to push to empty database

Copied from heroku/cli#372:

---

$ heroku pg:push localdb SILVER -r staging
heroku-cli: Pushing localdb ---> postgresql-nonsense-1234
 ▸    Remote database is not empty. Please create a new database or use heroku pg:reset
$ heroku pg:reset -r staging SILVER                          
 ▸    WARNING: Destructive action
 ▸    postgresql-nonsense-1234 will lose all of its data
 ▸
 ▸    To proceed, type tombstones-staging or re-run this command with --confirm myapp

> myapp
$ heroku pg:push localdb SILVER -r staging
heroku-cli: Pushing met_tombstones_development ---> postgresql-nonsense-1234
 ▸    Remote database is not empty. Please create a new database or use heroku pg:reset

SILVER is actually a new hobby-dev database. The existing DATABASE_URL database was also emptied when I ran into this issue and before I tried with a fresh database (I wanted to upgrade to 9.6.1 anyhow.)

---

See the original ticket for more details

Structured output from toolbelt commands, for use in scripts

As mentioned in heroku/cli#42, it's useful to be able to output JSON (or any other standardized structure) when a command is run in the CLI. Many CLI commands have --json as an option, but pg:info does not. I envision it like this:

$heroku pg:info
{
    "FOLLOWER_DATABASE": {
        "Plan": "Premium 2",
        "Following": "DATABASE",
        ...
    },
    "DATABASE": {
        "Plan": "Premium 4",
        ...
    }
}

`heroku pg:pull` produces lots of output to stderr

From heroku/cli#435:

$ heroku pg:pull DATABASE_URL db --app app > /dev/null
pg_restore: creating CONSTRAINT [..]
pg_restore: setting owner and privileges for FK CONSTRAINT [..]
[hundreds of lines]

$ heroku pg:pull DATABASE_URL db --app app > /dev/null 2>&1
$

Setting > /dev/null does nothing, but > /dev/null 2>&1 works to suppress output. But I don't really want to suppress potential errors. Am I doing anything wrong?

Poor error handling with no databases

Via @cyberdelia

maciek@mothra:~/code/aux/oki$ h pg:psql -a oki
 ▸    Unknown database: undefined. Valid options are:
maciek@mothra:~/code/aux/oki$ h addons -a oki
No add-ons for app oki.

Oki does have a DATABASE_URL, but it's a copy-and-paste from oki-cedar (and if we're doing this, others certainly also are). Ideally, we should either

• fall back to DATABASE_URL if there are no add-ons or attachments
• give a sensible error when there are no add-ons or attachments