Re: pg_restore -1 vs -C and -c
От | Tom Lane |
---|---|
Тема | Re: pg_restore -1 vs -C and -c |
Дата | |
Msg-id | 2001.1231780062@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_restore -1 vs -C and -c (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: pg_restore -1 vs -C and -c
Re: pg_restore -1 vs -C and -c |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > On 12 jan 2009, at 17.46, Tom Lane <tgl@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. >>> 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...) regards, tom lane
В списке pgsql-hackers по дате отправления: