Naz Gassiep <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, that implies a lack of error checking.
> Surely, then, that's a bug? Shouldn't postmaster check if a DB is in an
> encoding that differs from the selected locale?
Yeah, it should. Whether it can is a different question.
Part of th
Tom Lane wrote:
>> I've successfully created a utf8 database, does that imply that
>> because I was able to create a DB with a different encoding to the ones
>> all the others use (SQL_ASCII) that my locale is set to "C" ?
>>
>
> No, that implies a lack of error checking.
Surely, then, that's
Naz Gassiep <[EMAIL PROTECTED]> writes:
> OK I understand now, I think. How do I check what locale is currently
> set?
"show lc_collate" (maybe check the other lc_ settings too for luck).
> I've successfully created a utf8 database, does that imply that
> because I was able to create a DB with a
Tom Lane wrote:
> Are you clear on the difference between encoding and locale?
>
I confidently reply with "maybe".
> You can make new databases with whatever encoding you say, but the
> server's lc_collate and lc_ctype are frozen at initdb, and it will
> not work well to select an encoding tha
Naz Gassiep <[EMAIL PROTECTED]> writes:
> Why have I been told that I need to do a re initdb to change the char
> encoding? The man says i can just createdb foodb -E utf8so why
> would i need to dump/initdb/create/restore? cant i just dump/create/restore?
Are you clear on the difference be
Why have I been told that I need to do a re initdb to change the char
encoding? The man says i can just createdb foodb -E utf8so why
would i need to dump/initdb/create/restore? cant i just dump/create/restore?
It'd save all the messing around with changing the data dirs etc.
