Re: BUG #16679: Incorrect encoding of database name
От | Tom Lane |
---|---|
Тема | Re: BUG #16679: Incorrect encoding of database name |
Дата | |
Msg-id | 607290.1603207387@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16679: Incorrect encoding of database name (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > 1. Create database with name & encoding that won't binary match utf8 encoded > name, e.g: > create database Français > LC_COLLATE 'fr_FR@euro' LC_CTYPE 'fr_FR@euro' > encoding 'latin9' template template0; The short answer is don't do that. The name will be stored in pg_database with whatever encoding the source database (the one you were connected to while issuing CREATE DATABASE) uses, and then it will look funny from any database using another encoding. Connecting to the DB will also fail from any client not using the same encoding, since no encoding conversion is performed during startup-packet processing. Really the workable alternatives are (a) use only ASCII characters in database names, or (b) use the same encoding in every database of the cluster. Similar remarks apply to other globally-visible names, ie roles and tablespaces. It'd be nice in the abstract to have a better answer, but the amount of work required, relative to the practical benefit for people who aren't satisfied with either (a) or (b), is discouraging. Notable problems include what to do when a character in pg_database cannot be translated to the encoding you'd like to use. The connection-request encoding problem in particular seems insoluble without a protocol break, which would cause a lot more unhappiness than happiness. regards, tom lane
В списке pgsql-bugs по дате отправления: