From bc3bbe022c38567d0c9ec1f5445253e78edd0a49 Mon Sep 17 00:00:00 2001 From: Regina Obe Date: Thu, 21 Feb 2013 15:53:08 +0000 Subject: [PATCH] remove duped qandset tags git-svn-id: http://svn.osgeo.org/postgis/trunk@11108 b70326c6-7e19-0410-871a-916f4a2858ee --- doc/faq_raster.xml | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/doc/faq_raster.xml b/doc/faq_raster.xml index 5fd496999..8d38a698c 100644 --- a/doc/faq_raster.xml +++ b/doc/faq_raster.xml @@ -267,7 +267,6 @@ END We think it is a big advantage that raster structure should benefit as well. - @@ -277,14 +276,14 @@ END raster2pgsql doesn't make any connections to your database when generating the file to load. If your database has set an explicit client encoding different from your database encoding, then when loading large raster files (above 30 MB in size), you may run into a bytes is too long for encoding conversion. - This generally happens if for example you have your database in UTF8, but to support windows apps, you have the client encoding set to WIN1252. - To work around this make sure the client encoding is the same as your database encoding during load. You can do this by explicitly setting the encoding in your load script. Example, if you are on windows: - set PGCLIENTENCODING=UTF8 - If you are on Unix/Linux - export PGCLIENTENCODING=UTF8 + This generally happens if for example you have your database in UTF8, but to support windows apps, you have the client encoding set to WIN1252. + To work around this make sure the client encoding is the same as your database encoding during load. You can do this by explicitly setting the encoding in your load script. Example, if you are on windows: + set PGCLIENTENCODING=UTF8 + If you are on Unix/Linux + export PGCLIENTENCODING=UTF8 Gory details of this issue are detailed in http://trac.osgeo.org/postgis/ticket/2209 - - - + + + -- 2.50.1