Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On 12 jan 2009, at 17.46, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> However, one of the properties -1 is supposed to have is that any >>> failure aborts the whole restore; it's not immediately clear how to >>> preserve that with CREATE DATABASE issued separately. > >> Good point. Declare as incompatible it is, then :) it's not like it's >> hard do create the database before restoring. > > Works for me.
ok, will do. >>>> As for -c, the solution would be to issue DROP IF EXISTS >>>> statements. Is there any particular reason why we don't? >>> I think we did that to avoid damaging portability and backwards >>> compatibility of the dump files. The backwards compatibility argument >>> is pretty weak by now, but the "it's not standard SQL" argument still >>> has force. > >> IIRC the drop statements are generated by pg_restore and not stored in >> the archive. So we could do the if exists by default and have a switch >> to turn it off for a compatible dump, perhaps? > > No, the text of the statements is in the archive; though it might not be > too painful to have pg_restore edit them to insert "IF EXISTS". You > don't need an extra switch, just do this if -1 is in use (and document > that that switch reduces the standard-ness of the output...) I still think we need a separate parameter. DROP IF EXISTS would also be very useful along with -e, I think... //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
