Re: List of encodings - Mailing list pgsql-general

From Tom Lane
Subject Re: List of encodings
Date
Msg-id 83950.1776649770@sss.pgh.pa.us
Whole thread
In response to Re: List of encodings  (Ron Johnson <ronljohnsonjr@gmail.com>)
List 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



pgsql-general by date:

Previous
From: Ron Johnson
Date:
Subject: Re: List of encodings
Next
From: "Peter J. Holzer"
Date:
Subject: Re: List of encodings