Le 16/03/2012 10:25, Vik Reykja a écrit :
> I was helping someone restore a dump on Windows yesterday on IRC and the
> Restore button stayed disabled. I'd never had that problem before so I
> quickly created a new database, dumped it, and tried to restore it. I,
> too, got the disabled Restore button.
>
> Nothing I tried worked so I went into the source code to see what was up
> and saw the test for custom format. I checked my test dump and indeed
> it was plain.
>
> I don't know if you've ever tried to restore a dump through psql on the
> Windows command line but it's not easy, especially if you have non-ascii
> data. I propose a couple different solutions to make this situation better:
>
> 1- Don't disable the Restore button[1] or provide another means of
> letting the user know why restoration is not possible.
> 2- Automatically use psql when a plain dump is encountered. Guillaume
> Lelarge says the project doesn't want to package psql to avoid bloat.
> That's fine, but its presence can be tested for in "PG bin path" and
> used if found.
> 3- Make "custom" the default option when dumping. For a know-nothing
> newbie, dumping using the default options and immediately restoring
> using the default options should Just Work. Today it doesn't.
> 4- Allow pgAdmin to stream a file to the server. COPY can do this but I
> haven't looked into how exactly. This avoids having to open the plain
> dump in the sql editor which for any reasonably sized database will take
> forever and then die horribly (I've tried it).
>
I guess we would test the presence of psql, and allow to restore a PLAIN
dump if psql is available
I would also like to see custom being the default option of the backup tool.
Support for COPY...FROM stdin in the Query Tool would be nice to have,
but quite difficult to do.
Would you like to work on a patch?
--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com