Re: Add ENCODING option to COPY

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add ENCODING option to COPY
Дата
Msg-id 22957.1296834426@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add ENCODING option to COPY  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Ответы Re: Add ENCODING option to COPY  (Hitoshi Harada <umi.tanuki@gmail.com>)
Re: Add ENCODING option to COPY  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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.

> 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.

> * Can we use #ifndef FRONTEND in the header?
> Usage of fmgr.h members will broke client applications without the #ifdef,
> but I guess client apps don't always have definitions of FRONTEND.
> If we don't want to change pg_wchar.h, pg_conversion_fn.h might be
> a better header for the new API because FindDefaultConversion() is in it.

Yeah, putting backend-only stuff into that header is a nonstarter.
        regards, tom lane


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

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: CommitFest progress - or lack thereof
Следующее
От: Robert Haas
Дата:
Сообщение: Re: ALTER EXTENSION UPGRADE, v3