Tom Lane wrote:
> I'm wondering whether it would be appropriate to apply now despite being
> incomplete. The patch touches enough places in ecpg that code drift is
> likely to be a serious problem if it has to sit around for long.
We could do that, as soon as the author understands where the patc
Euler Taveira de Oliveira wrote:
> I don't know if I understand what you want to say by "call gettext". A
> quick look at the l10n of backend proves that it calls gettext
> everywhere. Could you ellaborate?
In nls.mk, you mark mmerror as containing arguments for translation, but
mmerror doesn't c
I'm a bit confused about where the consensus is on this issue (
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
et al)
Do we want the following:
1. pg_dump issues "set statement_timeout = 0;" to the database prior to
taking its copy of data (yes/no/default-but-switchable)
2. pg_
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Do we want the following:
> 1. pg_dump issues "set statement_timeout = 0;" to the database prior to
> taking its copy of data (yes/no/default-but-switchable)
> 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in text mode
> output (yes/no/defa
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Do we want the following:
1. pg_dump issues "set statement_timeout = 0;" to the database prior to
taking its copy of data (yes/no/default-but-switchable)
2. pg_dump/pg_restore issue "set statement_timeout = 0;" in text mode
output (y
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Mar 2008 10:46:23 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
And the -c version :) (thanks bruce)
Committed with slight editorializing. Statement timeout was only
introduced in 7.3, whereas pg_du
Andrew Dunstan wrote:
Committed with slight editorializing. Statement timeout was only
introduced in 7.3, whereas pg_dump can dump from much older versions of
Postgres.
You forget a ; in this committ [1].
[1] http://archives.postgresql.org/pgsql-committers/2008-05/msg00028.php
--
Euler
