public inbox for [email protected]  
help / color / mirror / Atom feed
From: Tom Lane <[email protected]>
To: Ron Johnson <[email protected]>
Cc: pgsql-generallists.postgresql.org <[email protected]>
Subject: Re: List of encodings
Date: Sun, 19 Apr 2026 21:49:30 -0400
Message-ID: <[email protected]> (raw)
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>
	<[email protected]>
	<CA+FnnTzx90AzTu07zVGMCYmvBYs_VsL9k2E7eBkzg_rTRwZbeA@mail.gmail.com>
	<[email protected]>
	<CA+FnnTxJyrnxR0hhV8T8J7Gb=MZ=OrtrEUcyoMf14-WHKgSb-A@mail.gmail.com>
	<CANzqJaBRRq5T-3VJc5fzGSOotAW8eXg1cvh0XwoRc4akO+mamg@mail.gmail.com>

Ron Johnson <[email protected]> writes:
> On Sun, Apr 19, 2026 at 9:13 PM Igor Korot <[email protected]> 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






reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: List of encodings
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox