On 2020/12/03 13:07, Tom Lane wrote:
Fujii Masao writes:
On 2020/12/03 1:04, Heikki Linnakangas wrote:
We never use non-default conversions for anything. All code that performs
encoding conversions only cares about the default ones.
Yes. I had to update pg_conversion.condefault directly
Fujii Masao writes:
> On 2020/12/03 1:04, Heikki Linnakangas wrote:
>> We never use non-default conversions for anything. All code that performs
>> encoding conversions only cares about the default ones.
> Yes. I had to update pg_conversion.condefault directly so that we can
> use custom encodin
On 2020/12/03 1:04, Heikki Linnakangas wrote:
Hi,
PostgreSQL allows writing custom encoding conversion functions between any
character encodings, using the CREATE CONVERSION command. It's pretty flexible,
you can define default and non-default conversions, and the conversions live in
schem
On 2020/12/03 11:48, tsunakawa.ta...@fujitsu.com wrote:
From: Michael Paquier
Tsunakawa-san, could you post a link to this article, if possible? I am curious
about their problem and why they used CREATE CONVERSION as a way to
solve it. That's fine even if it is in Japanese.
I just pulled
From: Michael Paquier
> Tsunakawa-san, could you post a link to this article, if possible? I am
> curious
> about their problem and why they used CREATE CONVERSION as a way to
> solve it. That's fine even if it is in Japanese.
I just pulled info from my old memory in my previous mail. Now the
> I recall a discussion in which someone explained that things are messy for
> Japanese because there's not really just one version of SJIS; there are
> several, because various groups extended the original standard in not-
> quite-compatible ways. In turn this means that there's not really one
>
On Thu, Dec 03, 2020 at 12:54:56AM +, tsunakawa.ta...@fujitsu.com wrote:
> I can't answer deeper questions because I'm not familiar with
> character sets, but I saw some Japanese web articles that use CREATE
> CONVERSION to handle external characters. So, I think we may as
> well retain it. (
"tsunakawa.ta...@fujitsu.com" writes:
> From: Heikki Linnakangas
>> Any objections? Anyone using custom encoding conversions in production?
> I can't answer deeper questions because I'm not familiar with character sets,
> but I saw some Japanese web articles that use CREATE CONVERSION to handle
From: Heikki Linnakangas
> I propose that we add a notice to the CREATE CONVERSION docs to say that
> it is deprecated, and remove it in a few years.
>
> Any objections? Anyone using custom encoding conversions in production?
I can't answer deeper questions because I'm not familiar with characte
Heikki Linnakangas writes:
> On 02/12/2020 18:18, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> I propose that we add a notice to the CREATE CONVERSION docs to say that
>>> it is deprecated, and remove it in a few years.
>> While I agree that it's probably not that useful, what would we gain
On 02/12/2020 18:18, Tom Lane wrote:
Heikki Linnakangas writes:
I propose that we add a notice to the CREATE CONVERSION docs to say that
it is deprecated, and remove it in a few years.
While I agree that it's probably not that useful, what would we gain
by removing it? If you intend to remov
Heikki Linnakangas writes:
> I propose that we add a notice to the CREATE CONVERSION docs to say that
> it is deprecated, and remove it in a few years.
While I agree that it's probably not that useful, what would we gain
by removing it? If you intend to remove those catalogs, what lookup
mechan
Hi,
PostgreSQL allows writing custom encoding conversion functions between
any character encodings, using the CREATE CONVERSION command. It's
pretty flexible, you can define default and non-default conversions, and
the conversions live in schemas so you can have multiple conversions
installed
13 matches
Mail list logo
