From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | COPY ENCODING revisited |
Date: | 2011-02-17 03:45:40 |
Message-ID: | AANLkTi=q+F7-sEnMs-b3etqW__-xEj=YzxUWxJif3s_J@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
COPY ENCODING patch was returned with feedback,
https://commitfest.postgresql.org/action/patch_view?id=501
but we still need it for file_fdw. Using client_encoding at runtime
is reasonable for one-time COPY command, but logically nonsense for
persistent file_fdw tables.
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.
According to Harada's research,
http://archives.postgresql.org/pgsql-hackers/2011-01/msg02397.php
non-cached conversions are slower than cached ones. This version provides
the same performance before when file and client encoding are same,
but would be a bit slower on other cases. We could improve the performance
in future versions, for example, caching each used conversion proc in
pg_do_pg_do_encoding_conversion().
file_fdw will support ENCODING option. Also, if not specified it might
have to store the client_encoding at CREATE FOREIGN TABLE. Even if we use
a different client_encoding at SELECT, the encoding at definition is used.
ENCODING 'quoted name' issue is also fixed; it always requires quoted names.
I think we only accept non-quoted text as identifier names. Unquoted text
should be treated as "double quoted", but encoding names are not identifiers.
--
Itagaki Takahiro
Attachment | Content-Type | Size |
---|---|---|
copy_encoding-20110217.patch | application/octet-stream | 19.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2011-02-17 03:45:49 | Re: Debian readline/libedit breakage |
Previous Message | Stephen Frost | 2011-02-17 03:39:11 | Re: Debian readline/libedit breakage |