couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amos Hayes <>
Subject Re: The replicator needs a superuser mode
Date Wed, 17 Aug 2011 17:12:09 GMT

We've strayed onto the topic of backup/restore/import/export and someone mentioned pg_dump,
so I'll toss this out there.

As a long time user of PostgreSQL and their import/export tools, I'd definitely suggest having
a look at what options have evolved in their tool too get a feel for what people might want
from a couch tool in the long run. Dumping users, schema, data, privileges, blobs, etc. or
disabling triggers, etc. are all options specified at the command line. Many of these options
could be mapped to couch concepts such as design docs, security objects, attachments, validation
processing, etc.

pg_dump is also careful to dump things in the order required for proper import. For couch,
this might mean dumping out in such a way that future imports would see data loaded before
design documents, etc.

Whether couchdb winds up with a command line tool or an authenticated URL with parameters
and possibly automation is an interesting question too. The former could well be built on
the latter.

FYI. Below is the pg_dump command line help from PostgreSQL 8.4 for reference. I hope it's


pg_dump dumps a database as a text file or to other formats.

  pg_dump [OPTION]... [DBNAME]

General options:
  -f, --file=FILENAME      output file name
  -F, --format=c|t|p       output file format (custom, tar, plain text)
  -i, --ignore-version     proceed even when server version mismatches
                           pg_dump version
  -v, --verbose            verbose mode
  -Z, --compress=0-9       compression level for compressed formats
  --help                   show this help, then exit
  --version                output version information, then exit

Options controlling the output content:
  -a, --data-only             dump only the data, not the schema
  -b, --blobs                 include large objects in dump
  -c, --clean                 clean (drop) schema prior to create
  -C, --create                include commands to create database in dump
  -d, --inserts               dump data as INSERT commands, rather than COPY
  -D, --column-inserts        dump data as INSERT commands with column names
  -E, --encoding=ENCODING     dump the data in encoding ENCODING
  -n, --schema=SCHEMA         dump the named schema(s) only
  -N, --exclude-schema=SCHEMA do NOT dump the named schema(s)
  -o, --oids                  include OIDs in dump
  -O, --no-owner              skip restoration of object ownership
                              in plain text format
  -s, --schema-only           dump only the schema, no data
  -S, --superuser=NAME        specify the superuser user name to use in
                              plain text format
  -t, --table=TABLE           dump the named table(s) only
  -T, --exclude-table=TABLE   do NOT dump the named table(s)
  -x, --no-privileges         do not dump privileges (grant/revoke)
  --disable-dollar-quoting    disable dollar quoting, use SQL standard quoting
  --disable-triggers          disable triggers during data-only restore
                              use SESSION AUTHORIZATION commands instead of
                              ALTER OWNER commands to set ownership

Connection options:
  -h, --host=HOSTNAME      database server host or socket directory
  -p, --port=PORT          database server port number
  -U, --username=NAME      connect as specified database user
  -W, --password           force password prompt (should happen automatically)

If no database name is supplied, then the PGDATABASE environment
variable value is used.

Report bugs to <>.


On 2011-08-17, at 10:11 AM, Noah Slater wrote:

> On 17 Aug 2011, at 11:06, Benoit Chesneau wrote:
>> Philosophy apart, dump and restore could be indeed useful to bootstrap
>> db, make plain backup/restore strategies, exchange dbs over a disk/mem
>> card without any couch installed etc.
> Yep, but in my mind this should live outside CouchDB's HTTP API. A dump and restore tool
that lived on the command line, like the Subversion hotcopy stuff is the first thing that
springs to mind. Or PostgreSQL's pgdump tool, or whatever. But as far as I understand the
current file format, you should be able to just rsync the .couch files while the database
is running.

View raw message