MinGW patch

I have applied the following patch to allow MinGW to again work on CVS.

THe patch makes the following changes:

o allow configure to see include/port/win32 include files
o add matching Win32 accept() prototype
o allow pg_id to compile with native Win32 API
o fix invalide mbvalidate() function calls (existing bug)
o allow /scripts to compile with native Win32 API
o add win32.c to Win32 compiles (already in *.mak files)

Other Win32 compile platforms were going to need some of these fixes
anyway.

These changes allow the first client-level compiles on Win32 using our
existing Makefile system (no *.mak), and not using Cygwin. All
interfaces and client apps work except for pg_resetxlog (no fsync).

With these patches, psql works using CMD.EXE:

U:\>psql -h 172.20.0.1 -U postgres test
Welcome to psql 7.4beta2, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=# select * from pg_language;
lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator | lanacl

----------+---------+--------------+---------------+--------------+---------------
internal | f | f | 0 | 2246 |
c | f | f | 0 | 2247 |
sql | f | t | 0 | 2248 | {=U/postgres}
(3 rows)

test=#

The backend still does not link.

The MinGW command console seems to have some problems with flushing
output to the screen (no prompt, no errors display), but the same binary
runs fine in CMD.EXE. We can look at that later.

I will update the WIN32 branch to match current CVS so all the Win32
fixes will be in that branch.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:

> + # We already have this in Makefile.win32, but configure needs it too
> + if test "$PORTNAME" = "win32"
> + then
> + CPPFLAGS="$CPPFLAGS -Isrc/include/port/win32"
> + fi

This seems unlikely to work when building outside the source tree.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
> > + # We already have this in Makefile.win32, but configure needs it too
> > + if test "$PORTNAME" = "win32"
> > + then
> > + CPPFLAGS="$CPPFLAGS -Isrc/include/port/win32"
> > + fi
>
> This seems unlikely to work when building outside the source tree.

Oh. Any ideas on how to handle that? The other reference uses:

override CPPFLAGS+="-I$(top_srcdir)/src/include/port/win32"

but top_srcdir isn't defined at this point. This is there only so
'configure' sees those include files. Does that relate to building
outside the tree?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> but top_srcdir isn't defined at this point.

Perhaps $srcdir? Peter would probably know what to use.

regards, tom lane

Bruce Momjian writes:

> Oh. Any ideas on how to handle that? The other reference uses:
>
> override CPPFLAGS+="-I$(top_srcdir)/src/include/port/win32"
>
> but top_srcdir isn't defined at this point.

If you put this in the port makefile, then it should work.

> This is there only so 'configure' sees those include files. Does that
> relate to building outside the tree?

Why does configure need to see those files? Surely you don't need
configure to test the capabilities of our own source tree?

--
Peter Eisentraut peter_e(at)gmx(dot)net

Bruce Momjian writes:

In mbprint.c:

+ #ifndef PGSCRIPTS
+ #include "settings.h"
+ #endif

Why is this needed, considering that the rest of the code was not changed
to make use of any setting? The print modules in psql should not make use
of psql-specific settings. That's why there are extensive separate
structures to pass this information.

Also, I'm beginning to feel that there are too many places where the lack
of getpwuid() is being worked around. That needs to be centralized.

Lastly, since there is not going to be a Windows port in 7.4, why was this
committed to the head branch?

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Why does configure need to see those files? Surely you don't need
> configure to test the capabilities of our own source tree?

Looking at the contents of src/include/port/win32, I would imagine the
problem is configure will decide we don't HAVE_SYS_SOCKET_H, etc.

regards, tom lane

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Oh. Any ideas on how to handle that? The other reference uses:
> >
> > override CPPFLAGS+="-I$(top_srcdir)/src/include/port/win32"
> >
> > but top_srcdir isn't defined at this point.
>
> If you put this in the port makefile, then it should work.

The problem is that the 'configure' doesn't find the include files
during its tests.

> > This is there only so 'configure' sees those include files. Does that
> > relate to building outside the tree?
>
> Why does configure need to see those files? Surely you don't need
> configure to test the capabilities of our own source tree?

As Tom mentioned, it doesn't find things like sys/socket.h, which we
have added to src/include/port/win32/. This was done to elimintate
#ifdef of the include files that are Win32-specific.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> In mbprint.c:
>
> + #ifndef PGSCRIPTS
> + #include "settings.h"
> + #endif
>
> Why is this needed, considering that the rest of the code was not changed
> to make use of any setting? The print modules in psql should not make use
> of psql-specific settings. That's why there are extensive separate
> structures to pass this information.

The problem is that mbvalidate() has this code:

if (GetVariableBool(pset.vars, "WIN32_CONSOLE"))
CharToOem(pwcs, pwcs);

That's why I needed the #ifdef so it only tests from psql. This code
was just broken without that test, and because no one else has done
Win32 compiles since it was added, no one saw it.

> Also, I'm beginning to feel that there are too many places where the lack
> of getpwuid() is being worked around. That needs to be centralized.

Yep. Let me add that to my list for 7.5.

> Lastly, since there is not going to be a Windows port in 7.4, why was this
> committed to the head branch?

Yes, I knew someone would ask, and debated it myself. Having these
patches in 7.4 allows us to have full-functional interfaces and client
binaries for MinGW. This allows us to show progress on the Win32 port,
and for folks to start using MinGW in client applications. Also, many
of these fixes will be needed for Cygwin and other Win32 platforms, so
it seemed best to fix them in head and just patch them back to the WIN32
branch.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Why does configure need to see those files? Surely you don't need
> > configure to test the capabilities of our own source tree?
>
> Looking at the contents of src/include/port/win32, I would imagine the
> problem is configure will decide we don't HAVE_SYS_SOCKET_H, etc.

Yep. Can anyone suggest a better solution?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

> The problem is that mbvalidate() has this code:
>
> if (GetVariableBool(pset.vars, "WIN32_CONSOLE"))
> CharToOem(pwcs, pwcs);
>
> That's why I needed the #ifdef so it only tests from psql. This code
> was just broken without that test, and because no one else has done
> Win32 compiles since it was added, no one saw it.

Interesting, considering that WIN32_CONSOLE isn't being set anywhere.

Anyway, that code needs to be removed/fixed, for the mentioned reasons.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The problem is that mbvalidate() has this code:
> >
> > if (GetVariableBool(pset.vars, "WIN32_CONSOLE"))
> > CharToOem(pwcs, pwcs);
> >
> > That's why I needed the #ifdef so it only tests from psql. This code
> > was just broken without that test, and because no one else has done
> > Win32 compiles since it was added, no one saw it.
>
> Interesting, considering that WIN32_CONSOLE isn't being set anywhere.
>
> Anyway, that code needs to be removed/fixed, for the mentioned reasons.

Yikes, I see no doc mention of it.

Here is the submission email:

> 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()

I have CC'ed the author.

Is this a valid feature? Should I document it?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

> Is this a valid feature? Should I document it?

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.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Bruce Momjian writes:

> As Tom mentioned, it doesn't find things like sys/socket.h, which we
> have added to src/include/port/win32/. This was done to elimintate
> #ifdef of the include files that are Win32-specific.

OK, then you can reference the top source directory as $srcdir in
configure.

--
Peter Eisentraut peter_e(at)gmx(dot)net

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?
>
> 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?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > As Tom mentioned, it doesn't find things like sys/socket.h, which we
> > have added to src/include/port/win32/. This was done to elimintate
> > #ifdef of the include files that are Win32-specific.
>
> OK, then you can reference the top source directory as $srcdir in
> configure.

OK, new code is:

if test "$PORTNAME" = "win32"
then
CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32"
fi

Thanks.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>>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?
>
>
>
Does input from the console work correctly right now?

What about setting the code page of the console to the ansi code page?
Or to the code page that postgresql uses internally.

SetConsoleCP(GetACP());
SetConsoleOutputCP(GetACP());

might be sufficient.

--
Manfred

On Sun, 7 Sep 2003 12:34:02 -0400 (EDT)
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

----- Original Message -----
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>; "PostgreSQL-patches"
<pgsql-patches(at)postgresql(dot)org>; "PostgreSQL Win32 port list"
<pgsql-hackers-win32(at)postgresql(dot)org>
Sent: Sunday, September 07, 2003 5:40 PM
Subject: Re: [pgsql-hackers-win32] [PATCHES] MinGW patch

> Tom Lane wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > > Why does configure need to see those files? Surely you don't need
> > > configure to test the capabilities of our own source tree?
> >
> > Looking at the contents of src/include/port/win32, I would imagine the
> > problem is configure will decide we don't HAVE_SYS_SOCKET_H, etc.
>
> Yep. Can anyone suggest a better solution?
>
I am seeing problem with HAVE_RL_FILENAME_COMPLETION_FUNCTION also on my
system. When I manually remove it from pg_config.h, psql compiles OK.

Regards !

Christoph Dalitz wrote:
> On Sun, 7 Sep 2003 12:34:02 -0400 (EDT)
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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?

Oh, sorry, I see it now. It is already in CVS:

<varlistentry>
<term><varname>WIN32_CONSOLE</varname></term>
<listitem>
<para>
This variable is only useful when working under the Win32 command
console. As the Win32 command console uses a different encoding than
the rest of the Windows system. Eight-bit characters (e.g. German Umlauts)
are corrupted. When this variable is set the command console encoding will
be translated into ASCII encoding for input and output.
</para>
</listitem>
</varlistentry>

I must have forgotten to do a case-insenstive grep.

> > > 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.

Got it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Christoph Dalitz writes:

> 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.

Maybe an environment variable?

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Sun, 07 Sep 2003 20:37:08 +0200
Manfred Spraul <manfred(at)colorfullife(dot)com> wrote:
>
> >>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.
> >>
> Does input from the console work correctly right now?
>
> What about setting the code page of the console to the ansi code page?
> Or to the code page that postgresql uses internally.
>
> SetConsoleCP(GetACP());
> SetConsoleOutputCP(GetACP());
>
> might be sufficient.
>
Shame on me!

Manfred's suggestion works perfectly. I did not realize this because the default
"rasterfont" for the win32 console cannot be used with codepage 1252 (windows
codepage on my system). When I switch to the font "Lucida Console" however, all
is fine with codepage 1252.

I have found this soultion here:
http://www.bei-priess.de/Perliges/perl-sonder.htm

Actually no psql tweaks are necessary at all, because the codepage for a console window
can be set with "cmd.exe /c chcp 1252". When I put this in my .bashrc, I actuallay
can use umlauts.

Sorry for producing some inconviniences in the psql devellopment.

The easiest would be to withdraw the WIN32_CONSOLE stuff from psql, replace it with
Manfred's solution and add to the documentation a tutorial how to make 8-bit characters
work in the Win32 console (with Manfred's solution, it actually only requires to set
the console font to "Lucida Console"). Alternatively no tweaks to psql could be done,
and the documentation should describe how the console can be forced to use the proper
encoding (this is certainly of interest to all win32 users of other applictaions as
well).

Christoph Dalitz

Christoph Dalitz writes:

> The easiest would be to withdraw the WIN32_CONSOLE stuff from psql, replace it with
> Manfred's solution and add to the documentation a tutorial how to make 8-bit characters
> work in the Win32 console (with Manfred's solution, it actually only requires to set
> the console font to "Lucida Console"). Alternatively no tweaks to psql could be done,
> and the documentation should describe how the console can be forced to use the proper
> encoding (this is certainly of interest to all win32 users of other applictaions as
> well).

Please send in a patch. Else, someone else is going to try to fix it with
less guarantees that it will work afterwards.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Wed, 10 Sep 2003 19:18:24 +0200 (CEST)
Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
> > The easiest would be to withdraw the WIN32_CONSOLE stuff from psql, replace it with
> > Manfred's solution and add to the documentation a tutorial how to make 8-bit characters
> > work in the Win32 console (with Manfred's solution, it actually only requires to set
> > the console font to "Lucida Console"). Alternatively no tweaks to psql could be done,
> > and the documentation should describe how the console can be forced to use the proper
> > encoding (this is certainly of interest to all win32 users of other applictaions as
> > well).
>
> Please send in a patch. Else, someone else is going to try to fix it with
> less guarantees that it will work afterwards.
>
Ok. I can do the following:

a) Write documentation how the win32 console needs to be set up so that
psql can handle 8-bit characters.
Where should it be added? The Section "Installation on Windows" in the
Administrator's Guide seems natural to me.

b) Add code to psql that prints a warning on startup of psql when the
console codepage differs from the windows codepage, something like

Warning: Console codepage (850) differs from windows codepage (1252)
8-bit characters will not work correctly. See PostgreSQL
documentation "Installation on Windows" for details.

Unfortunately there seems to be no automatic solution to the "console codepage problem",
because the windows codepage does not work with the default console font.
Thus the user must tweak his console settings in any case and I think a warning
is the best to remind the user of this issue.

Please let me know whether this "solution" would be ok. Then I can do it on Monday.

@Bruce:
-------

Could you please already remove the WIN32_CONSOLE and OemToChar/CharToOem stuff
from psql? Sorry for the inconvenience generated by my ignorance.

Christoph Dalitz

Christoph Dalitz wrote:
> > Please send in a patch. Else, someone else is going to try to fix it with
> > less guarantees that it will work afterwards.
> >
> Ok. I can do the following:
>
> a) Write documentation how the win32 console needs to be set up so that
> psql can handle 8-bit characters.
> Where should it be added? The Section "Installation on Windows" in the
> Administrator's Guide seems natural to me.
>
> b) Add code to psql that prints a warning on startup of psql when the
> console codepage differs from the windows codepage, something like
>
> Warning: Console codepage (850) differs from windows codepage (1252)
> 8-bit characters will not work correctly. See PostgreSQL
> documentation "Installation on Windows" for details.
>
> Unfortunately there seems to be no automatic solution to the "console codepage problem",
> because the windows codepage does not work with the default console font.
> Thus the user must tweak his console settings in any case and I think a warning
> is the best to remind the user of this issue.
>
> Please let me know whether this "solution" would be ok. Then I can do it on Monday.

Sounds good.

> @Bruce:
> -------
>
> Could you please already remove the WIN32_CONSOLE and OemToChar/CharToOem stuff
> from psql? Sorry for the inconvenience generated by my ignorance.

OK.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Christoph Dalitz writes:

> a) Write documentation how the win32 console needs to be set up so that
> psql can handle 8-bit characters.
> Where should it be added? The Section "Installation on Windows" in the
> Administrator's Guide seems natural to me.

Sure.

> b) Add code to psql that prints a warning on startup of psql when the
> console codepage differs from the windows codepage, something like
>
> Warning: Console codepage (850) differs from windows codepage (1252)
> 8-bit characters will not work correctly. See PostgreSQL
> documentation "Installation on Windows" for details.

If you can detect that they are different, why can't you adjust the code
page in that case only?

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:

>If you can detect that they are different, why can't you adjust the code
>page in that case only?
>
>
What should we do if we detect that they differ:
- set the console code page to the ansi code page. This has two
drawbacks: It doesn't work with Indic, because Indic doesn't have an
ansi code page. And the user must still switch the console font. But: if
the user must change the configuration, then he can as easily change
both the font and the code page. Which means: SetConsoleCP is the wrong
approach.
- OemToChar() and CharToOem() convert all console input/output. In the
long run this might be the better solution, if it works entirely without
user intervention. I'm not sure if it's possible to get all corner cases
right.

--
Manfred

On Thu, 11 Sep 2003 20:30:53 +0200 (CEST)
Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
> > b) Add code to psql that prints a warning on startup of psql when the
> > console codepage differs from the windows codepage, something like
> >
> > Warning: Console codepage (850) differs from windows codepage (1252)
> > 8-bit characters will not work correctly. See PostgreSQL
> > documentation "Installation on Windows" for details.
>
> If you can detect that they are different, why can't you adjust the code
> page in that case only?
>
Because 8-bit characters will not be displayed correctly unless the codepage
is set to the windows codepage *and* the console font is adjusted to a font
that is compatible with this codepage.

Unfortunately the default console font used in the german version of Windows
NT/2000/XP ("Rasterschriftart") is incompatible with the german windows codepage.
Thus the user must change the font to "Lucida Console" (that is the only alternative
font offered) in order to view 8-bit characters. AFAIK this font change cannot be done
automagically from within psql.

Why Microsoft does not configure the german version of Windows so that Umlauts work
out of the box in the console is a different story. Maybe they say: "Do not use
the console! If you do, we leave you in the rain!".

Christoph

On Thu, 11 Sep 2003 20:51:24 +0200
Manfred Spraul <manfred(at)colorfullife(dot)com> wrote:
>
> - OemToChar() and CharToOem() convert all console input/output. In the
> long run this might be the better solution, if it works entirely without
> user intervention. I'm not sure if it's possible to get all corner cases
> right.
>
I do not think that it is possible to handle all cases automatically.
Even restricting the conversion to input/output on stdin/stdout will fail in
some circumstances; eg. with the command "psql < script.sql" when the
script has been written with a windows editor (notepad, emacs or whatever).

That's why we introduced the WIN32_CONSOLE parameter, which was admittedly
not such a good idea and should be withdrawn.

Instructing the user how to set up the console so that 8-bit characters work
once and forever is the "rigth way" IMHO. The user will also profit from this
lesson when he uses some other console application, eg. the sqlite SQL-shell.

I will send in the "Win32 console setup instructions" next week.

Christoph

Christoph Dalitz wrote:

>On Thu, 11 Sep 2003 20:51:24 +0200
>Manfred Spraul <manfred(at)colorfullife(dot)com> wrote:
>
>
>>- OemToChar() and CharToOem() convert all console input/output. In the
>>long run this might be the better solution, if it works entirely without
>>user intervention. I'm not sure if it's possible to get all corner cases
>>right.
>>
>>
>>
>I do not think that it is possible to handle all cases automatically.
>Even restricting the conversion to input/output on stdin/stdout will fail in
>some circumstances; eg. with the command "psql < script.sql" when the
>script has been written with a windows editor (notepad, emacs or whatever).
>
It would be very hard to get right. Perhaps something like isatty(),
except that it's probably called GetHandleIsConsoleFlag() or something
like that, followed by a check of the code page. But I didn't find a
suitable function yet.

--
Manfred

Christoph Dalitz wrote:
> @Bruce:
> -------
>
> Could you please already remove the WIN32_CONSOLE and OemToChar/CharToOem stuff
> from psql? Sorry for the inconvenience generated by my ignorance.

Removed. Thanks.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073