On Fri, Feb 18, 2011 at 20:12, Itagaki Takahiro
wrote:
> + extern char *pg_any_to_server(const char *s, int len, int encoding);
> + extern char *pg_server_to_any(const char *s, int len, int encoding);
I applied the version with additional codes for file_fdw.
--
Itagaki Takahiro
--
Sent via pg
On Fri, Feb 18, 2011 at 03:57, Robert Haas wrote:
> On Wed, Feb 16, 2011 at 10:45 PM, Itagaki Takahiro
> I am not qualified to fully review this patch because I'm not all that
> familiar with the encoding stuff, but it looks reasonably sensible on
> a quick read-through. I am supportive of making
On Fri, Feb 18, 2011 at 04:04, Hitoshi Harada wrote:
> FWIW, I finally found the good example to cache miscellaneous data in
> file local, namely regexp.c. It allocates compiled regular expressions
> up to 32 by using malloc().
I'm not exactly sure the cache usage in mbutils.c because it doesn't
2011/2/17 Itagaki Takahiro :
> 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
On Wed, Feb 16, 2011 at 10:45 PM, Itagaki Takahiro
wrote:
> 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
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
