Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
ISTR being unconvinced by the pg_restore arguments, but as I think about it
some more, for someone to set statement_timeout on a production system, and
then have that be blindly overridden by any random pg_dump user seems a bit
unfair. pg_dump is not only used as a backup tool, it is also used as a
general user tool (for example, pgadmin calls pg_dump if you want to see a
tables schema).
So? In those usages, it's not going to run long enough to have a
statement_timeout problem anyway.
When there is a data dump involved, you still have to defend the
proposition that it's okay for pg_dump to deliver a bad dump if
statement_timeout hits it. I can't accept that.
I agree.
What is more, the solution to the non-dump uses of pg_dump is to put
that functionality in a library where clients can call it directly
rather than using pg_dump.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
