The default text search configuration will be set to "simple" ?

Stefan Schwarzer wrote:

Hi there,

what does this message mean? I didn't find any information on the web,
beside of others having similar messages...

------------------------------
The database cluster will be initialized with locales
COLLATE: en_US.UTF-8
CTYPE: UTF-8

This one is missing the en_US off the front. UTF-8 isn't a locale, it's
an encoding.

The default database encoding has accordingly been set to UTF8.

Good.

initdb: could not find suitable text search configuration for locale UTF-8

Bad. For some reason initdb isn't picking up your CTYPE setting
properly. What operating-system (and version) are you running, and what
version of PG, and did you compile it from source or get it elsewhere?

--
Richard Huxton
Archonet Ltd

what does this message mean? I didn't find any information on the
web, beside of others having similar messages...
------------------------------
The database cluster will be initialized with locales
COLLATE: en_US.UTF-8
CTYPE: UTF-8

This one is missing the en_US off the front. UTF-8 isn't a locale,
it's an encoding.

The default database encoding has accordingly been set to UTF8.

Good.

initdb: could not find suitable text search configuration for
locale UTF-8

Bad. For some reason initdb isn't picking up your CTYPE setting
properly. What operating-system (and version) are you running, and
what version of PG, and did you compile it from source or get it
elsewhere?

I am running 10.5, on a MacPro. Postgres version 8.3.1 and got it from
macports.

A bit ago, in my many attempts to get postgres & postgis running on
10.5, I added this to the .bash_profile:

adding to .bash_profile:
LANG=en_US.UTF-8; export LANG
export PATH="/opt/local/lib/postgresql83/bin:$PATH"

And then, something which didn't work before, did work finally. But I
am not eager to try it out now, because I am happy enough that my
postgres&postgis is finally running...

Stef

Stefan Schwarzer wrote:

properly. What operating-system (and version) are you running, and
what version of PG, and did you compile it from source or get it
elsewhere?

I am running 10.5, on a MacPro. Postgres version 8.3.1 and got it from
macports.

A bit ago, in my many attempts to get postgres & postgis running on
10.5, I added this to the .bash_profile:

adding to .bash_profile:
LANG=en_US.UTF-8; export LANG
export PATH="/opt/local/lib/postgresql83/bin:$PATH"

Hmm - very strange. Your LANG setting seems sensible, and I did
something similar on my Mac to get subversion to work. It could be that
the postgres user-account isn't importing these settings, but it
certainly seemed to get time/money/etc correct.

And then, something which didn't work before, did work finally. But I am
not eager to try it out now, because I am happy enough that my
postgres&postgis is finally running...

If it's nothing to do with the language settings, I'd check you have the
relevant files for tsearch. Look in $SHAREDIR/tsearch_data for a bunch
of <language>.stop files and perhaps .dict or .affix files

You can find out where your sharedir is with "pg_config --sharedir".

--
Richard Huxton
Archonet Ltd

Richard Huxton wrote:

Stefan Schwarzer wrote:

properly. What operating-system (and version) are you running, and
what version of PG, and did you compile it from source or get it
elsewhere?

I am running 10.5, on a MacPro. Postgres version 8.3.1 and got it from
macports.

A bit ago, in my many attempts to get postgres & postgis running on
10.5, I added this to the .bash_profile:

adding to .bash_profile:
LANG=en_US.UTF-8; export LANG
export PATH="/opt/local/lib/postgresql83/bin:$PATH"

Hmm - very strange. Your LANG setting seems sensible, and I did
something similar on my Mac to get subversion to work. It could be that
the postgres user-account isn't importing these settings, but it
certainly seemed to get time/money/etc correct.

It does make certain sense -- after all, LC_CTYPE is not worried about
country or language issues but only about encoding specifics. My
locale(7) manpage says

LC_CTYPE
This changes the behavior of the character handling and classifi-
cation functions, such as isupper(3) and toupper(3), and the
multi-byte character functions such as mblen(3) or wctomb(3).

On my system, though, locale does report the full locale, not just
encoding, when I change LANG.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

Stefan Schwarzer wrote:

I am running 10.5, on a MacPro. Postgres version 8.3.1 and got it from
macports.

On my system, though, locale does report the full locale, not just
encoding, when I change LANG.

Mine too. On my 10.5.2 machine initdb works as expected when I set
LANG to en_US.UTF-8. The only way I can reproduce the failure is to
*also* set LC_CTYPE to UTF-8 (without any en_US). That strikes me
as a configuration error. PG is looking at LC_CTYPE to decide what
text search config to select, and of course this value tells it
nothing about which language is in use ...

regards, tom lane