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
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 |