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