| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> | 
| Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: pg_restore -1 vs -C and -c | 
| Date: | 2009-01-12 17:07:42 | 
| Message-ID: | 2001.1231780062@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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.
>>> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2009-01-12 17:16:35 | Re: Recovery Test Framework | 
| Previous Message | Grzegorz Jaskiewicz | 2009-01-12 17:02:47 | Re: Recovery Test Framework |