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 16:46:47 |
Message-ID: | 1672.1231778807@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> It should be possible to make it compatible with -C by moving the CREATE
> DATABASE command to outside of the transaction. I have only had a quick
> look at the code wrt how much work this would be. One thing that hit me
> quickly: do we support multiple CREATE DATABASE statements in a single
> dump file? I think not, but the format seems to allow it? If not, it
> should be "fairly simple" to do.
We don't, and a single transaction couldn't restore into multiple
databases anyway. So in principle there's no reason we shouldn't allow
it to do the CREATE DATABASE, switch into the new DB, and then start the
transaction.
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.
Also you need to think about whether this might impact pg_dumpall.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-01-12 16:47:29 | Re: Recovery Test Framework |
Previous Message | Guillaume Smet | 2009-01-12 16:43:08 | Re: Recovery Test Framework |