| From: | Dave Page <dpage(at)pgadmin(dot)org> |
|---|---|
| To: | Harshal Dhumal <harshal(dot)dhumal(at)enterprisedb(dot)com> |
| Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
| Subject: | Re: Patch from RM1983 [pgAdmin4] |
| Date: | 2017-02-06 13:18:23 |
| Message-ID: | CA+OCxoypgUQjb2ki2fwokjAodz2nh4aCFOg6b388zFKweQq6Bw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgadmin-hackers |
Hi
On Mon, Feb 6, 2017 at 12:57 PM, Harshal Dhumal
<harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:
> Hi,
>
> Please find attached patch for RM 1983.
>
> This issue only occurs when database encoding is other than utf-8
>
> Also other issue was when we use connection of database with encoding other
> than utf-8 to retrieve data from cluster table/s which has encoding utf-8
> (e.g. pg_database) then data was not decoded properly.
The code makes an assumption that pg_database is always utf-8 encoded.
I don't believe that is correct - I believe it's the encoding used in
the database from which the new database was created. The general
advice is that users should avoid using non-7bit ASCII characters in
shared catalogs, e.g. databases and comments etc.
See https://www.postgresql.org/message-id/flat/20160216163833(dot)GF31273%40momjian(dot)us#20160216163833(dot)GF31273(at)momjian(dot)us
for more info for example.
Did pgAdmin 3 just assume it was UTF-8? I suspect it did - and that
just happened to work in most cases.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Harshal Dhumal | 2017-02-06 14:54:50 | Re: Patch from RM1983 [pgAdmin4] |
| Previous Message | Harshal Dhumal | 2017-02-06 12:57:42 | Patch from RM1983 [pgAdmin4] |