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
copy_encoding-20110217.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
