Alvaro Herrera <alvhe...@commandprompt.com> writes: > Kevin Grittner escribió: >> Robert Haas <robertmh...@gmail.com> wrote: > Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers