upper and lower doesn't work with german umlaut?

=?ISO-8859-1?Q?=22K=F6nig=2C_Frank=22?= <Frank.Koenig@rossmann.de> writes:

uppercase umlauts are not converted.

Did you run initdb with the correct LANG environment?

To check, run contrib/pg_controldata and see what it says about
LC_COLLATE and LC_CTYPE.

regards, tom lane

"K�nig, Frank" writes:

./configure --prefix=$DIR_DEST --exec-prefix=$DIR_DEST
--enable-local --enable-multibyte

^^^^^
locale

--enable-odbc --enable-syslog --with-java

--
Peter Eisentraut peter_e@gmx.net

"K?nig, Frank" writes:

./configure --prefix=$DIR_DEST --exec-prefix=$DIR_DEST
--enable-local --enable-multibyte

^^^^^
locale

--enable-odbc --enable-syslog --with-java

And why does configure ignore flags it doesn't support. I sure don't
like that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

And why does configure ignore flags it doesn't support. I sure don't
like that.

Complain to the GNU people. I've always considered this a serious bug
in autoconf, but they steadfastly maintain it's a feature.

regards, tom lane

Tom Lane a �crit :

=?ISO-8859-1?Q?=22K=F6nig=2C_Frank=22?= <Frank.Koenig@rossmann.de> writes:

uppercase umlauts are not converted.

Did you run initdb with the correct LANG environment?

To check, run contrib/pg_controldata and see what it says about
LC_COLLATE and LC_CTYPE.

I have relativily the same problem! Where can I find the executable "contrib"
?
Thanks!

On Tue, 27 Nov 2001 Vincent.Gaboriau@answare.fr wrote:

Tom Lane a ���crit :

=?ISO-8859-1?Q?=22K=F6nig=2C_Frank=22?= <Frank.Koenig@rossmann.de> writes:

uppercase umlauts are not converted.

Did you run initdb with the correct LANG environment?

To check, run contrib/pg_controldata and see what it says about
LC_COLLATE and LC_CTYPE.

I have relativily the same problem! Where can I find the executable "contrib"
?

contrib refers to the contrib directory at the top level of the source
tree.

Stephan Szabo a �crit :

On Tue, 27 Nov 2001 Vincent.Gaboriau@answare.fr wrote:

Tom Lane a �crit :

=?ISO-8859-1?Q?=22K=F6nig=2C_Frank=22?= <Frank.Koenig@rossmann.de> writes:

uppercase umlauts are not converted.

Did you run initdb with the correct LANG environment?

To check, run contrib/pg_controldata and see what it says about
LC_COLLATE and LC_CTYPE.

I have relativily the same problem! Where can I find the executable "contrib"
?

contrib refers to the contrib directory at the top level of the source
tree.

The sources of postgres have been deleted, so I can't find this "contrib"!
So I surch another way to know if postgres have been installed with the local
configuration.
Can anyone help me?

On Tue, 27 Nov 2001 Vincent.Gaboriau@answare.fr wrote:

Stephan Szabo a ���crit :

On Tue, 27 Nov 2001 Vincent.Gaboriau@answare.fr wrote:

Tom Lane a ���crit :

=?ISO-8859-1?Q?=22K=F6nig=2C_Frank=22?= <Frank.Koenig@rossmann.de> writes:

uppercase umlauts are not converted.

Did you run initdb with the correct LANG environment?

To check, run contrib/pg_controldata and see what it says about
LC_COLLATE and LC_CTYPE.

I have relativily the same problem! Where can I find the executable "contrib"
?

contrib refers to the contrib directory at the top level of the source
tree.

The sources of postgres have been deleted, so I can't find this "contrib"!
So I surch another way to know if postgres have been installed with the local
configuration.
Can anyone help me?

You might be able to get it by looking through the
<data dir>/global/pg_control file, but it's a binary file so you'll have
to search for it.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2001 November 27 11:08 am, Vincent.Gaboriau@answare.fr wrote:

To check, run contrib/pg_controldata and see what it says about
LC_COLLATE and LC_CTYPE.

I have relativily the same problem! Where can I find the executable
"contrib" ?

contrib refers to the contrib directory at the top level of the source
tree.

The sources of postgres have been deleted, so I can't find this "contrib"!

Under debian linux, it is
/usr/lib/postgresql/bin/pg_controldata
You should be able to find it quickly using
% locate pg_controldata
Alternately, if your system isn't properly maintained (and, unless you've got
some seriously nice hardware, this will take some time: grab a coffee while
you wait...), try
% find / -name 'pg_controldata' -print 2> /dev/null

- --
Andrew G. Hammond mailto:drew@xyzzy.dhs.org http://xyzzy.dhs.org/~drew/
56 2A 54 EF 19 C0 3B 43 72 69 5B E3 69 5B A1 1F 613-389-5481
5CD3 62B0 254B DEB1 86E0 8959 093E F70A B457 84B1
"To blow recursion you must first blow recur" -- me
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwDzroACgkQCT73CrRXhLGCDgCfcWiJQWBl25oDh1qkgliH9hZz
ORIAnAtcWijMWTZXtWKWiPUorVz82GXU
=9Tyz
-----END PGP SIGNATURE-----

The sources of postgres have been deleted, so I can't find this "contrib"!
So I surch another way to know if postgres have been installed with the local
configuration.
Can anyone help me?

You might be able to get it by looking through the
<data dir>/global/pg_control file, but it's a binary file so you'll have
to search for it.

I had found it, but I don't know speak fluent binary language ;-)
Does a way exist to "decompile" it or to get informations on it?

Thanks.

Vincent.Gaboriau@answare.fr writes:

You might be able to get it by looking through the
<data dir>/global/pg_control file, but it's a binary file so you'll have
to search for it.

I had found it, but I don't know speak fluent binary language ;-)
Does a way exist to "decompile" it or to get informations on it?

If you can't be troubled to compile up pg_controldata, then you'll
have to resort to good old od:

$ od -c pg_control
0000000 314 201 030 267 255 u 344 277 \0 \0 \0 G 013 355 p 253
0000020 \0 \0 \0 004 < 004 ) 006 \0 \0 \0 \0 \0 \0 \0 8
0000040 \0 \0 \0 \0 7 026 e 210 \0 \0 \0 \0 7 026 D h
0000060 \0 \0 \0 \0 7 026 e 210 \0 \0 \0 \0 \0 \0 \0 \0
0000100 \0 \0 \0 \t \0 001 357 235 \0 017 017 354 < 004 ) 004
0000120 \0 \0 \0 \0 002 \0 \0 C \0 \0 \0 \0 \0 \0 \0
0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000320 \0 \0 \0 \0 \0 \0 \0 \0 C \0 \0 \0 \0 \0 \0 \0
0000340 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0020000

The LC_COLLATE and LC_CTYPE locale strings should be the last nonzero
things in the file --- they're both "C" in this example.

regards, tom lane

Tom Lane a �crit :

Vincent.Gaboriau@answare.fr writes:

You might be able to get it by looking through the
<data dir>/global/pg_control file, but it's a binary file so you'll have
to search for it.

I had found it, but I don't know speak fluent binary language ;-)
Does a way exist to "decompile" it or to get informations on it?

If you can't be troubled to compile up pg_controldata, then you'll
have to resort to good old od:

$ od -c pg_control
0000000 314 201 030 267 255 u 344 277 \0 \0 \0 G 013 355 p 253
0000020 \0 \0 \0 004 < 004 ) 006 \0 \0 \0 \0 \0 \0 \0 8
0000040 \0 \0 \0 \0 7 026 e 210 \0 \0 \0 \0 7 026 D h
0000060 \0 \0 \0 \0 7 026 e 210 \0 \0 \0 \0 \0 \0 \0 \0
0000100 \0 \0 \0 \t \0 001 357 235 \0 017 017 354 < 004 ) 004
0000120 \0 \0 \0 \0 002 \0 \0 C \0 \0 \0 \0 \0 \0 \0
0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000320 \0 \0 \0 \0 \0 \0 \0 \0 C \0 \0 \0 \0 \0 \0 \0
0000340 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0020000

The LC_COLLATE and LC_CTYPE locale strings should be the last nonzero
things in the file --- they're both "C" in this example.

Thanks to Tom Lane!
But I have This in my pg_control file:

# od -c pg_control
0000000 \0 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0
0000020 � 006 004 < 004 \0 \0 \0 \0 \0 \0 \0 \0 002 \0
0000040 � � � \v \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0020000
#

So no LC_COLLATE and LC_TYPE in the pg_control. But these variables are set in
the user environement!

Vincent.Gaboriau@answare.fr writes:

But I have This in my pg_control file:

# od -c pg_control
0000000 \0 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0
0000020 � 006 004 < 004 \0 \0 \0 \0 \0 \0 \0 \0 002 \0
0000040 � � � \v \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0020000
#

Er ... *what* version did you say you were running? That doesn't look
like a 7.1 pg_control to me.

regards, tom lane

Tom Lane a �crit :

Vincent.Gaboriau@answare.fr writes:

But I have This in my pg_control file:

# od -c pg_control
0000000 \0 \0 \0 \0 001 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0
0000020 � 006 004 < 004 \0 \0 \0 \0 \0 \0 \0 \0 002 \0
0000040 � � � \v \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0020000
#

Er ... *what* version did you say you were running? That doesn't look
like a 7.1 pg_control to me.

No, I have an 7.0.2 on Linux Mandrake 7.2.

Vincent.Gaboriau@answare.fr writes:

Er ... *what* version did you say you were running? That doesn't look
like a 7.1 pg_control to me.

No, I have an 7.0.2 on Linux Mandrake 7.2.

Time to update then. 7.0 doesn't freeze the LC_COLLATE setting at
initdb, which means that you can corrupt your indexes by starting the
postmaster with different LC settings at different times. Which is
depressingly easy to do.

regards, tom lane

Tom Lane a �crit :

Vincent.Gaboriau@answare.fr writes:

Er ... *what* version did you say you were running? That doesn't look
like a 7.1 pg_control to me.

No, I have an 7.0.2 on Linux Mandrake 7.2.

Time to update then. 7.0 doesn't freeze the LC_COLLATE setting at
initdb, which means that you can corrupt your indexes by starting the
postmaster with different LC settings at different times. Which is
depressingly easy to do.

Ok! And does the new version correct my character sequences error?

Vincent.Gaboriau@answare.fr writes:

Ok! And does the new version correct my character sequences error?

Which was ...?

regards, tom lane

Tom Lane a �crit :

Vincent.Gaboriau@answare.fr writes:

Ok! And does the new version correct my character sequences error?

Which was ...?

Refer to " [ADMIN] character sequence problem"

Thanks for your help.

regards, Vincent.

Vincent.Gaboriau@answare.fr writes:

Ok! And does the new version correct my character sequences error?

Which was ...?

Oh, never mind (for some reason my first search for your previous
messages didn't turn up anything).

I'm not sure. The LIKE queries you were complaining of didn't look like
they could use an index anyway, so index corruption wouldn't explain
misbehavior there. But I'd recommend updating from 7.0 to 7.1
regardless.

regards, tom lane