Re: pg_restore --single-transaction and --clean

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Kevin Grittner escribi:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> We try to avoid using nonstandard SQL in dumps.

>>> How often do we succeed? It seems unlikely that our dumps would
>>> be restorable into any other database.

>> When we were running in a mixed environment we had several occasions
>> where it was useful to feed pg_dump --column-inserts output into
>> Sybase databases. It was very nice to have that. I think we did
>> sometimes have to filter it through sed to deal with BOOLEAN vs BIT
>> issues.

> Maybe we should have a --compatible-mode or some such that enables these
> things, instead of staying away from useful PG-only features.

Well, the subtext of my comment was really that this case isn't useful
enough to justify introducing a nonstandard construct into dumps.
IMO the whole *point* of --single-transaction is to fail if the database
isn't in the state you thought it was. If you want to restore into an
empty DB with --single-transaction, don't use --clean. Problem solved.

--clean has got other issues anyway with a DB that isn't in exactly the
expected state. If the inter-object dependencies aren't quite what they
were in the source, drops are likely to fail because dependent objects
still remain. Should we therefore make all pg_dump's drop commands
CASCADE? I don't think so; the side-effects could be nasty.

regards, tom lane