Thread: The default text search configuration will be set to "simple" ?
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
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 localesCOLLATE: en_US.UTF-8CTYPE: 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