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
MESSAGES: en_US.UTF-8
MONETARY: en_US.UTF-8
NUMERIC: en_US.UTF-8
TIME: en_US.UTF-8
The default database encoding has accordingly been set to UTF8.
initdb: could not find suitable text search configuration for locale
UTF-8
The default text search configuration will be set to "simple".
------------------------------

Thanks for any advice,

Stef

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general