From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | alexander(dot)kass(at)jetbrains(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16679: Incorrect encoding of database name |
Date: | 2020-10-20 15:23:07 |
Message-ID: | 607290.1603207387@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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(at)euro' LC_CTYPE 'fr_FR(at)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Christensen | 2020-10-20 16:18:20 | Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return |
Previous Message | David Christensen | 2020-10-20 14:23:06 | Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return |