From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com> |
Cc: | "pgadmin-support lists(dot)postgresql(dot)org" <pgadmin-support(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SQL_ASCII support (or lack thereof) |
Date: | 2018-05-17 14:17:52 |
Message-ID: | CA+OCxoyxTG9KmQZ5Tn8naz6SEHj1LMVJMduuZFtfeSGoA2cr3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
On Thu, May 17, 2018 at 3:06 PM, richard coleman <
rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
> Why is pgAdmin 4 so hostile to SQL_ASCII databases?
>
> We have several production databases dating back to 9.1 that are SQL_ASCII
> encoding but in pgAdmin4 I am constantly having to *clean up* non *UTF8* data.
> The same data works just fine in the pgAdmin3 series.
>
> Running the same query in psql yields the expected results, but in this
> case I get:
>
> "ERROR: invalid byte sequence for encoding "UTF8": 0xc9 0x4f
> SQL state: 22021"
>
> in pgAdmin4.
>
> If I remove the offending characters then pgAdmin4 returns a result set.
> The database is SQL_ASCII encoded, pgAdmin4 *shouldn't care* that there
> are non UTF8 characters present.
>
pgAdmin doesn't - Python does. If you can give some examples, we may be
able to figure out the issue and work around it.
It's worth noting though that it's usually a bad idea to use SQL_ASCII
(that's not intended as an excuse, just as some advice).
--
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 | 2018-05-17 14:32:12 | Re: Error on accessing SQL tab for triggers |
Previous Message | richard coleman | 2018-05-17 14:06:03 | SQL_ASCII support (or lack thereof) |