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

From Hitoshi Harada
Subject Re: Add ENCODING option to COPY
Date
Msg-id AANLkTinRrC9od6fiKk5xmWm7E0WX5JjT0xPHL8O9DoqD@mail.gmail.com
Whole thread Raw
In response to Re: Add ENCODING option to COPY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add ENCODING option to COPY  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: pl/python custom datatype parsers
Next
From: Tom Lane
Date:
Subject: Re: Add ENCODING option to COPY