Re: [HACKERS] ecpg localization

2008-05-03 Thread Peter Eisentraut
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 patch would need 
to go, as discussed elsewhere in this thread.

-- 
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] ecpg localization

2008-05-03 Thread Peter Eisentraut
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 call gettext anywhere, so nothing would get translated at run 
time.  To pick up your backend example, we mark arguments of errmsg() for 
translation, but then errmsg() calls gettext.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] statement timeout vs dump/restore

2008-05-03 Thread Andrew Dunstan


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_dump/pg_restore issue set statement_timeout = 0; in text mode 
output (yes/no/default-but-switchable)
3. pg_restore issues set statement_timeout = 0; to the database in 
restore mode (yes/no/default-but-switchable)


I would tend to say default-but-switchable for all 3, but maybe that's 
too complicated.


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


Re: [HACKERS] statement timeout vs dump/restore

2008-05-03 Thread Tom Lane
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/default-but-switchable)
 3. pg_restore issues set statement_timeout = 0; to the database in 
 restore mode (yes/no/default-but-switchable)

I think yes for all three.  There was some handwaving about someone
maybe not wanting it, but an utter lack of convincing use-cases; so
I see no point in going to the effort of providing a switch.

Note that 2 and 3 are actually the same thing (if you think they are
not, then you are putting the behavior in the wrong place).

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] statement timeout vs dump/restore

2008-05-03 Thread Joshua D. Drake

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 (yes/no/default-but-switchable)
3. pg_restore issues set statement_timeout = 0; to the database in 
restore mode (yes/no/default-but-switchable)


I think yes for all three.  There was some handwaving about someone
maybe not wanting it, but an utter lack of convincing use-cases; so
I see no point in going to the effort of providing a switch.

Note that 2 and 3 are actually the same thing (if you think they are
not, then you are putting the behavior in the wrong place).


Right, pg_restore just using the output from pg_dump. The dump has the 
statement_timeout. That way it works regardless of output (e.g; for psql 
text based restores).


Sincerely,

Joshua D. Drake



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] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

2008-05-03 Thread Andrew Dunstan



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_dump can dump from much older versions of 
Postgres.


Also, the indentation needed fixing.

wiki updated.

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


Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

2008-05-03 Thread Euler Taveira de Oliveira

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 Taveira de Oliveira
  http://www.timbira.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers