Peter Eisentraut <[EMAIL PROTECTED]> writes: > Christopher Kings-Lynne wrote: >> * We have a request for how to change database encoding every other >> day
> This is pretty much impossible. It's analogous to changing, say, the > endianness of all integers. You would need to rewrite the entire > database. But pg_dump & restore already does that. I wonder though, do the requestors actually know what they're asking for? Are they really asking for encoding changes, or are they asking for locale changes? >> (i suggest a warning in initdb if no encoding is specified - >> EVERY pgsql newbie fails to set it) > Hm... initdb already tells you pretty clearly what locale it's picking. I think people don't read the message and/or don't understand the implications. IMHO the *real* issues here boil down to two things: 1. You can't change locale after initdb. Even a per-database locale setting would be better than that (though of course the SQL spec sets the bar much higher, namely per-column locales). 2. You can shoot yourself in the foot by selecting a database encoding that's not compatible with the (fixed) locale. AFAICS there is not very much we can do about either of these things without creating our own locale support layer so we can stop depending on the standard C library's inflexible and taciturn API. Peter has mentioned that he is working on that but that it might be a year or so before it's ready. Is that still a reasonable guess? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])