On Mon, Feb 6, 2017 at 6:48 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi On Mon, Feb 6, 2017 at 12:57 PM, Harshal Dhumal <harshal.dhumal@enterprisedb.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.
Ok.
Let me split this into two issues:
i) RM1983 for which I have attached updated patch. (basically I removed changes related to decode data retried from pg_database when connection encoding is other than utf-8)
ii) Support to allow user to use non-&bit ASCII characters in shared catalogs with the help of pgAdmin4.
Regarding your statement about pg_database "I believe it's the encoding used in the database from which the new database was created.". I found it little-bit confusing for me (correct me if i'm wrong); As mentioned here there is only one copy of pg_database per cluster. So I assume pg_database is created when we initialize database cluster and not when we create new database.
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