On Sun, 7 Sep 2003 12:34:02 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Peter Eisentraut wrote:
>
> > c) Problem: 8bit characters were displayed/interpreted wrong in psql
> > This is due to the fact that the Win32 "console" uses a
> > different encoding than the rest of the Windows system
> > Solution: Introduced a new psql variable WIN32_CONSOLE
> > When set with "\set WIN32_console", the function OemToChar()
>
> > Bruce Momjian writes:
> >
> > > Is this a valid feature? Should I document it?
> >
We have documented it and included a patch for the psql documentation.
Was it applied?
> > Maybe it's a valid feature, but the implementation is not valid.
> > Other applications also make use of the print routines (e.g., createlang),
> > and they cannot interactively set variables. So I repeat: the print
> > routines may not access the psql settings.
> >
> > I think we ought to detect the console type automatically anyway.
> > Certainly we don't want people to have to set this variables all the time.
>
> Agreed. Automatic is ideal. Any ideas out there?
>
Automatic detection does not work in all situation. The problem is a Microsoft
insanity: the win32 "console" uses a different encoding *only on stdin and
stdout*, not when accessing files. Thus it must be possible to set the parameter
WIN32_CONSOLE manually. Sample psql session:
psql> insert into tabelle values 'bäh'; -- here we need OemToChar()
psql> select * from tabelle; -- here we need CharToOem()
psql> \i script.sql -- here CharToOem() must NOT be used
Note that this will not be observed in English speaking countries! The problem
only occurs in other languages, which is the reason why most authors of win32
software do not even know about this problem.
Another soulution would be, not to compile psql as a console application, but
as a windows application and write an own terminal emulator. This solution
however faces another win32 insanity: windows applications have no stdout.
Christoph Dalitz
