Alvaro Herrera <alvherre@commandprompt.com> writes:
> Kevin Grittner escribi�:
>> Robert Haas <robertmhaas@gmail.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.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
