Re: Add ENCODING option to COPY

Поиск
Список
Период
Сортировка
От Hitoshi Harada
Тема Re: Add ENCODING option to COPY
Дата
Msg-id AANLkTinRrC9od6fiKk5xmWm7E0WX5JjT0xPHL8O9DoqD@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add ENCODING option to COPY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add ENCODING option to COPY  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2011/2/5 Tom Lane <tgl@sss.pgh.pa.us>:
> Itagaki Takahiro <itagaki.takahiro@gmail.com> writes:
>> * Syntax: ENCODING encoding vs. ENCODING 'encoding'
>> We don't have to quote encoding names in the patch, but we always need
>> quotes for CREATE DATABASE WITH ENCODING. I think we should modify
>> CREATE DATABASE to accept unquoted encoding names aside from the patch.
>
> The reason that we use quotes in CREATE DATABASE is that encoding names
> aren't assumed to be valid SQL identifiers.  If this patch isn't
> following the CREATE DATABASE precedent, it's the patch that's wrong,
> not CREATE DATABASE.

What about SET client_encoding TO encoding?

>> Changes in pg_wchar.h are the most debatable parts of the patch.
>> The patch adds pg_cached_encoding_conversion(). We normally use
>> pg_do_encoding_conversion(), but it is slower than the proposed
>> function because it lookups conversion proc from catalog every call.
>
> Why should callers need to be changed for that?  Just make the existing
> function use caching.

Because the demanded behavior is similar to
pg_client_to_server/server_to_client, which caches functions as
specialized client encoding and database encoding as the file local
variables. We didn't have such spaces to cache functions for other
encoding conversions, so decided to cache them in CopyState and pass
them to the mb routine.

Regards,


--
Hitoshi Harada


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: pl/python custom datatype parsers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Add ENCODING option to COPY