-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
Bruce asks: >>> Particularly consider using psql to restore a pg_dump >>> dump --- are we going to add "SET statement_timeout=0" >>> to the pg_dump file? > >> I hope not. That should be the user's choice. > Would anyone want to limit the load time for pg_dump? I > can hardly see why. Not for pg_dump, but for psql, as you stated above. I don't have a problem adding it to pg_dump or pg_restore. They are single, atomic actions out of the control of the user. Restoring a pg_dump'ed file through psql, on the other hand, should not assume that the user might not want to keep or set their own timeout, perhaps because they want to limit the load on the server, or because of vacuuming concerns. Recall that pg_dump is not just used to restore entire systems: we can dump schemas, tables, and in the near future may even have the ability to dump different classes (schema, data, constraints). Hard-coding a forced option to the top of a potentially ginormous and hard-to-edit file that really has nothing to do with the data itself seems the wrong way to do things. It's not as if we've been inundated on the lists with tales of people getting caught on custom statement_timeouts when importing dumps. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200803111959 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkfXHqMACgkQvJuQZxSWSsgifQCgthvDCTiKhw/3A4S1na1mvlOB +MQAn2baL34c8k3FV+f2CUAn7GwDewrN =x24Q -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
