Re: List of encodings
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ron Johnson <ronljohnsonjr@gmail.com>
Cc: "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Date: 2026-04-20T01:49:30Z
Lists: pgsql-general
Ron Johnson <ronljohnsonjr@gmail.com> writes: > On Sun, Apr 19, 2026 at 9:13 PM Igor Korot <ikorot01@gmail.com> wrote: >> Since all 3 are default character sets, which one would be chosen? >> (in the context of CREATE DATABASE) > Does CREATE DATABASE *convert text*? (I think you might be > misunderstanding the purpose of the pg_conversion table.) Indeed. I doubt that CREATE DATABASE references this catalog at all. > Wouldn't it only *convert* text when a client is inserting text of encoding > X into a table with encoding Y? In the current system structure, where conversion actually happens is at the client interface, when sending/receiving data. All text that's running around inside a backend process is expected to be in the database's encoding, and we convert if the client has declared that it wants to work in some other encoding. So the pg_conversion catalog is actually consulted during connection startup, to see if we can support the requested client_encoding with the database encoding. There is also the convert() function, which allows you to convert a blob of text from one encoding to another --- but the input and output are both declared as bytea, so that they don't have to be valid in the current database encoding. IIRC, the client conversion lookups will only choose "condefault" conversions, so that a non-default conversion is only reachable via convert(). So that feature is really pretty vestigial. regards, tom lane