On Sat, Mar 12, 2016 at 5:43 PM, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> On Sat, Mar 12, 2016 at 05:31:38PM -0700, David G. Johnston wrote: > > > > The reason being, of course, that I want to check the exit > > > code in a pg_restore wrapper script. > > > > > > > > I mistakenly thought public only came from template1...I wouldn't be > > opposed to that change. This all seems awfully familiar too... > > > > You probably should just drop the existing database and use --create by > > itself. > > > > You can even use the dropdb command to avoid SQL in your script. > > I already do something similar: the wrapper fails if the > target db exists before a restore is even attempted. The > restore itself now uses --create and works as expected. The > only thing left ATM is that I cannot distinguish > success-with-or-without-ignored-errors from real failure. > > I _can_ partly work around that by attempting to connect to > the target and checking the md5 sum of the schema definition > against a known hash. That won't help with detecting whether > pg_restore thought that _data_ was successfully restored ... > > I'd operate under the premise that all warnings and errors are fatal (i.e., keep --exit-on-error) until you cannot for some very specific reason. I'd decide how to proceed at that point. For instance pg_restore does provide an ignored error count at the end - you could scan the log for expected errors, count them, and compare to that value and fail if the count differs. But this particular warning should be easy to work around and you shouldn't expect any others that would be considered non-critical. David J.
