Re: COPY ENCODING revisited - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: COPY ENCODING revisited
Date
Msg-id AANLkTikg82oxn8z2Kj7RfvizKV3nGhdaXXTeQp8a4fPa@mail.gmail.com
Whole thread Raw
In response to COPY ENCODING revisited  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: COPY ENCODING revisited
List pgsql-hackers
2011/2/17 Itagaki Takahiro <itagaki.takahiro@gmail.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: contrib loose ends: 9.0 to 9.1 incompatibilities
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.