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.
