Re: [HACKERS] pg_restore --single-transaction and --clean
Takahiro Itagaki itagaki.takah...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore --single-transaction and --clean
On Wed, Feb 10, 2010 at 10:16 AM, Tom Lane t...@sss.pgh.pa.us wrote: Takahiro Itagaki itagaki.takah...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore --single-transaction and --clean
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. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore --single-transaction and --clean
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. The problem would then be how to test it ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore --single-transaction and --clean
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
Re: [HACKERS] pg_restore --single-transaction and --clean
Tom Lane escribió: 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. That's true, but this is not the first time we've left out some feature from dumps because they would make them standards-incompatible. If we have enough of these (and I have no idea that we do), maybe we could start here. This is of course just a future TODO item, not something to consider for 9.0. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
