On Thu, Jul 1, 2010 at 9:54 AM, Sam Mason <sam@samason.me.uk> wrote:
> On Thu, Jul 01, 2010 at 09:47:03AM -0700, Mike Christensen wrote:
>> On Thu, Jul 1, 2010 at 9:44 AM, Sam Mason <sam@samason.me.uk> wrote:
>> > On Thu, Jul 01, 2010 at 09:31:12AM -0700, Mike Christensen wrote:
>> >> Then, I edited the file in Notepad and saved it as UTF8 which also
>> >> appears to have worked.
>> >
>> > I don't think you want to be doing this. The file should contain a "set
>> > client_encoding" of the correct value which will let PG to do the "right
>> > thing" when you import it back into a UTF8 database.
>>
>> Yup, that fixed it. I had to change the DB.dbs.out file to use the
>> new encoding. Duh! Everything's working now.
>
> AFAIK, you should be able to leave the file exactly as it came out of
> pg_dump and PG will do all the conversions automatically.
>
> If you've not checked already, it may be worth checking through to see
> what row was on line 170 and see if it's got the right thing in there
> now.
>
> --
> Sam http://samason.me.uk/
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
Yup, the problem is line 170 doesn't actually match up to the
DB.dbs.out file line 170 (which is a blank line). I believe it means
line 170 from the stdin pipe it was processing for the copy command.
Suffice to say, there was some weird character in my database that PG
can't automatically translate from WIN1252 to UTF8, and apparently it
will drop that /entire/ COPY command (the entire table doesn't get
populated!)..
As to what character was the culprit, I'm not entirely sure how to
figure this out. I guess I could look for that hex value? However,
if I set the encoding in the script itself, everything works
perfectly.
I'm not sure this is a PG bug or anything, but having more detail on
this error might be helpful.
Mike