Tom Lane wrote:
> Magnus Hagander writes:
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 compatibil
Tom Lane wrote:
> Magnus Hagander writes:
>> On 12 jan 2009, at 17.46, Tom Lane 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
Magnus Hagander writes:
> On 12 jan 2009, at 17.46, Tom Lane 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 incomp
On 12 jan 2009, at 17.46, Tom Lane wrote:
Magnus Hagander 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
qui
Magnus Hagander 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 s
Hi!
As I think has been previously noted, using pg_restore with -1 (single
transaction) is fundamentally incompatible with -C (we can't CREATE
DATABASE inside a transaction) and often incompatible with -c (we don't
do DROP IF EXISTS, so if the objects don't exist the entire restore will
fail). It
