From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_restore -1 vs -C and -c |
Date: | 2009-01-13 09:48:07 |
Message-ID: | 496C6357.7070708@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On 12 jan 2009, at 17.46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-01-13 09:59:52 | Re: Recovery Test Framework |
Previous Message | Magnus Hagander | 2009-01-13 09:44:12 | Re: Recovery Test Framework |