feat: support custom format, plain sql and cluster dumps
This commit is contained in:
17
README.md
17
README.md
@@ -83,10 +83,23 @@ ahab django make-command <app> <name>
|
||||
## postgres
|
||||
|
||||
```bash
|
||||
ahab postgres dump <path> # pg_dump, custom format
|
||||
ahab postgres import <path> # drop, create, pg_restore
|
||||
ahab postgres dump <path> # pg_dump, custom format
|
||||
ahab postgres dump -F plain <path> # pg_dump, plain sql
|
||||
ahab postgres import <path> # drop, create, then restore
|
||||
```
|
||||
|
||||
The format of a dump being imported is read from the file rather than its name.
|
||||
A custom format dump starts with `PGDMP` and a tar one with `toc.dat`, both of
|
||||
which go to `pg_restore`, as does a directory produced by `pg_dump -Fd`.
|
||||
Anything else is treated as sql and fed to `psql` with `ON_ERROR_STOP` and
|
||||
`--single-transaction`, so a bad file rolls back instead of half applying.
|
||||
A whole cluster dump from `pg_dumpall` is recognised by its header and handled
|
||||
differently again: it creates its own databases and carries role statements, so
|
||||
the database is dropped but not recreated, the dump goes to `psql` connected to
|
||||
`postgres`, and it runs without `ON_ERROR_STOP` because roles that already exist
|
||||
report errors that are expected. Gzipped dumps are decompressed on the way in,
|
||||
whichever of the three they hold.
|
||||
|
||||
## link
|
||||
|
||||
`ahab link` moves untracked paths out of the repository into an out-of-repo
|
||||
|
||||
Reference in New Issue
Block a user