Re: Add ENCODING option to COPY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add ENCODING option to COPY
Date
Msg-id 22957.1296834426@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add ENCODING option to COPY  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: Add ENCODING option to COPY  (Hitoshi Harada <umi.tanuki@gmail.com>)
Re: Add ENCODING option to COPY  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: CommitFest progress - or lack thereof
Next
From: Robert Haas
Date:
Subject: Re: ALTER EXTENSION UPGRADE, v3