pg_restore --single-transaction and --clean
in [PgSql]
|
From: Tom Lane on 10 Feb 2010 10:16 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > Is it a TODO item to replace "DROP" into "DROP IF EXISTS" > for cleanup commands in pg_restore? No. We try to avoid using nonstandard SQL in dumps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 10 Feb 2010 11:17 On Wed, Feb 10, 2010 at 10:16 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: >> Is it a TODO item to replace "DROP" into "DROP IF EXISTS" >> for cleanup commands in pg_restore? > > No. 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. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 10 Feb 2010 11:27 Robert Haas <robertmhaas(a)gmail.com> wrote: > Tom Lane <tgl(a)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. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 10 Feb 2010 11:30 Kevin Grittner escribi�: > Robert Haas <robertmhaas(a)gmail.com> wrote: > > Tom Lane <tgl(a)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. The problem would then be how to test it ... -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 10 Feb 2010 11:43 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Kevin Grittner escribi�: >> Robert Haas <robertmhaas(a)gmail.com> wrote: > Tom Lane <tgl(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: Parameter name standby_mode Next: [PATCH] Output configuration status after ./configure run. |