Re: [Fwd: Re: dblink patches for comment] - Mailing list pgsql-hackers

Tom Lane wrote:
> But that reminds me, weren't you going to add something to force
> libpq to set client_encoding to the database encoding?

I think the attached is what you had in mind. But I don't know right off
how to trigger the failure (and therefore how to test the solution). A
naive test with two databases, one LATIN2, the other UTF8 does not
produce the error with simple text literals. Any guidance on specific
literals that would trigger the problem?

Thanks,

Joe

Index: dblink.c
===================================================================
RCS file: /opt/src/cvs/pgsql/contrib/dblink/dblink.c,v
retrieving revision 1.79
diff -c -r1.79 dblink.c
*** dblink.c    6 Jun 2009 21:27:56 -0000    1.79
--- dblink.c    7 Jun 2009 01:14:44 -0000
***************
*** 48,53 ****
--- 48,54 ----
  #include "executor/spi.h"
  #include "foreign/foreign.h"
  #include "lib/stringinfo.h"
+ #include "mb/pg_wchar.h"
  #include "miscadmin.h"
  #include "nodes/execnodes.h"
  #include "nodes/nodes.h"
***************
*** 185,190 ****
--- 186,192 ----
                               errdetail("%s", msg))); \
                  } \
                  dblink_security_check(conn, rconn); \
+                 PQsetClientEncoding(conn, GetDatabaseEncodingName()); \
                  freeconn = true; \
              } \
      } while (0)
***************
*** 263,268 ****
--- 265,273 ----
      /* check password actually used if not superuser */
      dblink_security_check(conn, rconn);

+     /* attempt to set client encoding to match server encoding */
+     PQsetClientEncoding(conn, GetDatabaseEncodingName());
+
      if (connname)
      {
          rconn->conn = conn;