dump encoding (was Re: [HACKERS] 8.2 beta blockers)

2006-09-18 Thread Tom Lane 
Michael Paesold [EMAIL PROTECTED] writes:
 * Set client encoding based on OS environment - Peter E.

 I really hope that this change will only affect psql, not pg_dump, as Peter 
 wrote in 2003. I would strongly object to such a change (as much as my 
 voice counts). The current behavior of dumping with the database encoding 
 is exactly the right thing to do.

Actually, I realize after a quick look at the pg_dump code that its
current behavior is to dump in
1. Specified encoding if a -E switch is given.
2. PGCLIENTENCODING, if that environment var exists.
3. Else, server encoding.
So there's already an environment dependency, although it's for
something much less likely to be set than LANG.  I tend to agree
that we'd better avoid having dumps depend on LANG ... wonder if
we should remove the dependency on PGCLIENTENCODING too.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: dump encoding (was Re: [HACKERS] 8.2 beta blockers)

2006-09-18 Thread Peter Eisentraut 
Am Montag, 18. September 2006 15:48 schrieb Tom Lane:
 So there's already an environment dependency, although it's for
 something much less likely to be set than LANG.  I tend to agree
 that we'd better avoid having dumps depend on LANG ... wonder if
 we should remove the dependency on PGCLIENTENCODING too.

I'd say that in principle, any console application should respect the 
console's encoding settings by default.  pg_dump is not only a backup tool 
but also useful for quasi-interactive use.  We could check if stdout goes to 
a terminal or something like that.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq