Ticket #1303 (closed defect: wontfix)

Opened 18 months ago

Last modified 16 months ago

[PATCH] shp2pgsql does not respect PGCLIENTENCODING

Reported by: etourigny Owned by: mcayland
Priority: medium Milestone: PostGIS 1.5.4
Component: loader/dumper Version: 1.5.X
Keywords: shp2pgsql, PGCLIENTENCODING Cc:

Description

To avoid encoding problems, one has to use the -W encoding option to shp2pgsql.

However, the PGCLIENTENCODING variable is designed to force all clients to use a different encoding and is easier to use than manually setting the encoding for all imports.

It seems that shp2pgsql does not respect that variable.

I have written a simple fix against 1.5.3 (tested in Ubuntu 11.04).

--- shp2pgsql-core.c~	2010-12-13 18:42:47.000000000 -0200
+++ shp2pgsql-core.c	2011-11-16 21:34:20.000000000 -0200
@@ -961,7 +961,11 @@
 	config->forceint4 = 0;
 	config->createindex = 0;
 	config->readshape = 1;
-	config->encoding = strdup(ENCODING_DEFAULT);
+	/* config->encoding = strdup(ENCODING_DEFAULT); */
+    if ( getenv("PGCLIENTENCODING") != NULL )
+        config->encoding = strdup(getenv("PGCLIENTENCODING"));
+    else
+        config->encoding = strdup(ENCODING_DEFAULT);
 	config->null_policy = POLICY_NULL_INSERT;
 	config->sr_id = -1;
 	config->hwgeom = 0;

Change History

Changed 18 months ago by mcayland

  • status changed from new to closed
  • resolution set to wontfix

The reason that we don't do anything with the PGCLIENTENCODING variable is because shp2pgsql doesn't use PostgreSQL to perform the encoding conversion, but instead uses the iconv library.

Both PostgreSQL and iconv have different sets of supported conversion tables (and even different names in some cases), and so there is no guarantee that an encoding specified in PGCLIENTENCODING would necessarily either exist or work in the same way when being used with iconv. Hence I am closing this as "won't fix".

Changed 18 months ago by etourigny

Ok I understand.

However, the error message is a bit misleading, as it refers to the way postgres deals with encodings. It would be clearer to refer to the iconv library instead. Thanks.

Try "LATIN1" (Western European), or one of the values described at http://www.postgresql.org/docs/current/static/multibyte.html.

Changed 18 months ago by mcayland

Ah yes, that's definitely wrong - I'd say the appropriate link should be  http://www.gnu.org/s/libiconv/ instead.

Paul - any objections if I change this?

Changed 18 months ago by pramsey

Go for it.

Changed 16 months ago by mcayland

Done in trunk (r9033) and 1.5 branch (r9034).

Note: See TracTickets for help on using tickets.