From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ron Johnson <ronljohnsonjr@gmail.com>
cc: "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Subject: Re: List of encodings
In-reply-to: <CANzqJaBRRq5T-3VJc5fzGSOotAW8eXg1cvh0XwoRc4akO+mamg@mail.gmail.com>
References: <CA+FnnTxFMiA+KMfypfGyY43G2kSx6-t5A351snUMmWC-2Lxvaw@mail.gmail.com> <CAKFQuwZOH6BPtaWJKr9jRGxdJt05YtLAZn1s_fYt=uzAASm9CQ@mail.gmail.com> <CA+FnnTymNs9_3pBci01_Uu5OTNJFngOhu8_khpmUs88V8kX86Q@mail.gmail.com> <71cd4015-9002-4173-bd9a-075f7afb3c20@aklaver.com> <CA+FnnTzx90AzTu07zVGMCYmvBYs_VsL9k2E7eBkzg_rTRwZbeA@mail.gmail.com> <5f263a8a-9c30-4118-b410-6e25eafde156@aklaver.com> <CA+FnnTxJyrnxR0hhV8T8J7Gb=MZ=OrtrEUcyoMf14-WHKgSb-A@mail.gmail.com> <CANzqJaBRRq5T-3VJc5fzGSOotAW8eXg1cvh0XwoRc4akO+mamg@mail.gmail.com>
Comments: In-reply-to Ron Johnson <ronljohnsonjr@gmail.com>
	message dated "Sun, 19 Apr 2026 21:31:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <83949.1776649770.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sun, 19 Apr 2026 21:49:30 -0400
Message-ID: <83950.1776649770@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/83950.1776649770%40sss.pgh.pa.us>
Precedence: bulk

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