Rohit Goyal wrote > Hi Peter, > > On Tue, May 13, 2014 at 9:44 PM, Peter Geoghegan <
> pg@ > > wrote: > >> >> On Tue, May 13, 2014 at 12:36 PM, Rohit Goyal < > rhtgyl.87@ > > wrote: >> >>> This pattern the above found many times. Please guide me through!!! >>> >> >> IIRC, people have been working around this by setting >> standard_conforming_strings to "off". It really ought to be fixed in a >> principled way, though -- the real issue here is that dbt2 has severe >> bit-rot. >> >> Can you please elaborate, where I can make this changes :) ? Peter? The error is more typical of someone creating a database with UTF-8 encoding but then tries storing Latin-1 (or some other) encoded data. Since not all byte sequences in the source data encoding are valid in UTF-8 when one of the invalid sequences is present the import fails. PostgreSQL makes no attempt to perform data conversion on import. The solution is to create the database with the correct encoding - whatever it may be. This "DBT2" application should provide guidance on this topic. Otherwise you could use "SQL_ASCII" - which is effectively punting on the issue: http://www.postgresql.org/docs/9.3/static/sql-createdatabase.html http://www.postgresql.org/docs/9.3/static/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED IIRC given that the error happens in a SQL COPY "standard_conforming_strings" has no bearing on the outcome. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Error-in-running-DBT2-tp5803793p5803817.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers