Re: SQL_ASCII support (or lack thereof)

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

In response to

Responses

Browse pgadmin-support by date

  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)