#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: |
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 (5)
comment:1 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 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 http://www.postgresql.org/docs/current/static/multibyte.html.
comment:3 by , 13 years ago
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?
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".