From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Single-Transaction Utility options |
Date: | 2005-12-19 03:03:27 |
Message-ID: | 13727.1134961407@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I once considered implementing this myself but found it infeasible for
> some reason I don't remember. Nevertheless I always thought that
> having an atomic restore ought to be a non-optional feature. Are there
> situations where one would not want to use it?
Absolutely. As a nontrivial example, I *very* often load dumps sent to
me by other people which are full of GRANT/REVOKE commands referencing
users that don't exist in my installation. Since, most of the time,
I don't particularly care about the ownership/privileges of the tables
involved, having to create those users would just be a PITA.
More generally, the pg_dump output has always been designed around the
assumption that failed commands are non-fatal. Look at all those
unportable SET commands that we don't give you an option to omit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2005-12-19 03:03:40 | Re: COPY LOCK for WAL bypass |
Previous Message | Bruce Momjian | 2005-12-19 02:21:56 | Test, please ignore |