Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#1303 closed defect (wontfix)

[PATCH] shp2pgsql does not respect PGCLIENTENCODING

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


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 (5)

comment:1 by mcayland, 13 years ago

Resolution: wontfix
Status: newclosed

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".

comment:2 by etourigny, 13 years ago

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

comment:3 by mcayland, 13 years ago

Ah yes, that's definitely wrong - I'd say the appropriate link should be instead.

Paul - any objections if I change this?

comment:4 by pramsey, 13 years ago

Go for it.

comment:5 by mcayland, 12 years ago

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

Note: See TracTickets for help on using tickets.