Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Dave Rolsky <autarch@urth.org>, pgsql-bugs@postgresql.org
Date: 2013-02-19T13:00:07Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- conditional-drops.patch (application/octet-stream) patch
Hello 2013/2/16 Pavel Stehule <pavel.stehule@gmail.com>: > 2013/2/16 Tom Lane <tgl@sss.pgh.pa.us>: >> Bruce Momjian <bruce@momjian.us> writes: >>> On Fri, Feb 15, 2013 at 04:06:12PM -0600, Dave Rolsky wrote: >>>> Fair enough. It should probably an option to add "if exists", at >>>> least. I can't imagine I'm the only using this tool to ship database >>>> updates around to different machines, some of which may not have new >>>> tables. I'd really like to be able to know when the restore fails >>>> versus when it succeeds but is noisy. >> >>> All I can say is I don't remember anyone asking for this in the past. >> >> I think it has come up before. I wouldn't object to a pg_dump option to >> add IF EXISTS to all the drop commands (though changing the default >> behavior would be more controversial). Don't intend to spend my own >> time on it though ... > > we use this feature more than one year. > > I'll send patch at Monday here is patch, that we use about one year - originally for 9.1 - I did port to 9.3 Regards Pavel > > Regards > > Pavel Stehule > > > >> >> regards, tom lane >> >> >> -- >> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-bugs