Re: COPY ENCODING revisited

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY ENCODING revisited
Date: 2011-02-17 19:04:01
Message-ID: AANLkTikg82oxn8z2Kj7RfvizKV3nGhdaXXTeQp8a4fPa@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/2/17 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> Base on the latest patch,
>  http://archives.postgresql.org/pgsql-hackers/2011-01/msg02903.php
> I added pg_any_to_server() and pg_server_to_any() functions instead of
> exposing FmgrInfo in pg_wchar.h.  They are same as pg_client_to_server()
> and pg_server_to_client(), but accept any encoding. They use cached
> conversion procs only if the specified encoding matches the client encoding.

It sounds good to me since the approach doesn't make any overhead to
the current behavior, although additional ENCODING option usage gets a
bit slower. Nothing lost.

FWIW, I finally found the good example to cache miscellaneous data in
file local, namely regexp.c. It allocates compiled regular expressions
up to 32 by using malloc(). We need only 4 or so for encoding
conversion cache, in which cache search doesn't seem like overhead. I
don't have time to make it as patch, but in a few days I'll try it.

Regards,

--
Hitoshi Harada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-02-17 19:04:59 Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Previous Message Robert Haas 2011-02-17 18:58:14 Re: contrib loose ends: 9.0 to 9.1 incompatibilities