Re: COPY ENCODING revisited

Поиск
Список
Период
Сортировка
От Hitoshi Harada
Тема Re: COPY ENCODING revisited
Дата
Msg-id AANLkTikg82oxn8z2Kj7RfvizKV3nGhdaXXTeQp8a4fPa@mail.gmail.com
обсуждение исходный текст
Ответ на COPY ENCODING revisited  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Ответы Re: COPY ENCODING revisited  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: contrib loose ends: 9.0 to 9.1 incompatibilities
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.