Re: BUG #16679: Incorrect encoding of database name

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

In response to

Browse pgsql-bugs by date

  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