Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Nanina Tron <nanina(dot)tron(at)icloud(dot)com>
Cc: richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>, "pgadmin-support lists(dot)postgresql(dot)org" <pgadmin-support(at)lists(dot)postgresql(dot)org>
Subject: Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3
Date: 2019-01-09 10:16:32
Message-ID: CA+OCxoz8XJeL0vrNAins1BpuFLNXw_kOKG=OjygHk2TH4AoHhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support

Hi

On Wed, Jan 9, 2019 at 3:29 PM Nanina Tron <nanina(dot)tron(at)icloud(dot)com> wrote:
>
> Hi,
> thanks for trying. Yes the backup included the invalid data, but we've just found the problem.
> The 'special' characters in the data are handled just fine, but not if they are present in the column names.
> So does pgAdmin handle both data differently or is it Postgres? I thought if the db is encoded UTF8 the this wouldn't be a problem.

It depends on what part of pgAdmin we're talking about. The
import/export tool hands off the task to psql - it will only try to
look at column names to let you select a subset if you choose. Other
areas will touch the data as well.

That said, with your dump loaded into a SQL_ASCII database, we do seem
to get a failure when trying to reverse engineer the columns. I'll ask
one of the devs to look into that.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgadmin-support by date

  From Date Subject
Next Message Murtuza Zabuawala 2019-01-09 12:42:48 Re: "Statistics" tab is very slow
Previous Message Nanina Tron 2019-01-09 09:59:32 Re: Import/Export failure due to UTF-8 error in pgAdmin4 but not in pgAdmin3