Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fPsat-0007C2-4d for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jun 2018 16:44:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fPsar-0006US-UD for pgadmin-hackers@arkaria.postgresql.org; Mon, 04 Jun 2018 16:44:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fPsar-0006UG-Jq for pgadmin-hackers@lists.postgresql.org; Mon, 04 Jun 2018 16:44:29 +0000 Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fPsaj-0002vd-De for pgadmin-hackers@postgresql.org; Mon, 04 Jun 2018 16:44:28 +0000 Received: by mail-lf0-x244.google.com with SMTP id u4-v6so26282771lff.3 for ; Mon, 04 Jun 2018 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qN6D9T+lr4xpmImfTveds2aMKhjfCHwTIqEabnEjr+8=; b=MqrXVdUYtEXVe1+Zq5Ca0pY97DTdWmkxIlStUNtEr0WRi2kr4WJqJ/B47toyCPWaMZ HhkvyTG8hzw0r2kGgkfp8AITNKw1hPExyiocqMqdXK8wB5yNxsUhsaIQBCRAuaizZRrR Z5VLAL7+ARW8if+5pQYATHN/mmFzpOaXiTRnIX34sBOk+wKQAgVBZyrIAKUaVBOYh7X5 9oJk40RMlJIraSl5rmyVND7IxGybM16nsrAA/6B/XJ9emODYZKaS0JQcu6ooez8sv96+ 6nwUJUrrK/H8Oswyciqn8/wXdN95AtR4hQQKTcJ/z6LIy5r4OKD/fzRhm7nUaCrxI7jM g3hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qN6D9T+lr4xpmImfTveds2aMKhjfCHwTIqEabnEjr+8=; b=mE+OzThYKEqibniZANBeL4XHsycUtzwF2eoolNhVFUg7Wsya0yD6LDFPze0jdh/g28 RL2H4ON9FsH+ADEZZ+iX+oWdVCLeESkU1Mx5l6Y3ocVqT2XP5K0cHggDMewGql6/iBW+ +GeMD2oU06YMGg6JgCYFV10SjWIbbhlyMQJ/2g9ByC49FXrus4HX2Ld/f915ElZ6Y7+S weRG8ACO5vMmpfPpZLor/cI/V5mS1tCNgts0eE6x0EyK2ii8/7gZyelyYgx0Uv0eYnEp sdb7hMSBuYzthE3wZFTEIvHafGuboblLLG/69fb/XWjX7pS+RAT76Uwtvv12010itj5Y Jqqg== X-Gm-Message-State: ALKqPweDIbOZUPZsgwJeK+jus2rqxcNtZI05mr9EmCGH1PrMEpZNYInh 48lpRUTHsejkveMLKHn+cyeEjSiCzVNIQieqBcI8mo8i X-Google-Smtp-Source: ADUXVKLToen3m9dQoootvLBqFcUN1r6Q31vwDlKOf3s7q5zZZrcWqLiLi1RYZ/BtXUJs/0B6niGitOAU852NWUMNcqA= X-Received: by 2002:a2e:9e10:: with SMTP id e16-v6mr15558392ljk.108.1528130660179; Mon, 04 Jun 2018 09:44:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:9e8a:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 09:44:19 -0700 (PDT) In-Reply-To: References: From: Aditya Toshniwal Date: Mon, 4 Jun 2018 22:14:19 +0530 Message-ID: Subject: Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database. To: Joao De Almeida Pereira Cc: Dave Page , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000002bbab2056dd3a520" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000002bbab2056dd3a520 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Victoria/Joao, There is no change related to notifications in this patch. The below code is minor fix related to connection status of sql editor. Can you please share the code snippet if it is not the below. - # Check for the asynchronous notifies statements. - conn.check_notifies(True) - notifies =3D conn.get_notifies() + if status is not None: + # Check for the asynchronous notifies statements. + conn.check_notifies(True) + notifies =3D conn.get_notifies() The test cases work perfectly fine on my machine. I will try if I can simulate the failure on some other machines. Thanks and Regards, Aditya Toshniwal Software Engineer | EnterpriseDB Software Solutions | Pune "Don't Complain about Heat, Plant a tree" On Mon, Jun 4, 2018 at 8:54 PM, Joao De Almeida Pereira < jdealmeidapereira@pivotal.io> wrote: > Hi Aditya, > Looks like there are changes in this patch that are related to > notifications, these should go into a separate commit as they are not > related to encoding. > Also the tests are failing in our pipeline: https://gpdb-dev. > bosh.pivotalci.info/teams/pgadmin/pipelines/pgadmin- > patch/jobs/run-tests/builds/110 > > Thanks > Victoria && Joao > > On Mon, Jun 4, 2018 at 5:55 AM Aditya Toshniwal enterprisedb.com> wrote: > >> Hi Hackers, >> >> Please ignore previous patch. Fixed some linter issues. PFA updated patc= h. >> >> Thanks and Regards, >> Aditya Toshniwal >> Software Engineer | EnterpriseDB Software Solutions | Pune >> "Don't Complain about Heat, Plant a tree" >> >> On Mon, Jun 4, 2018 at 10:53 AM, Aditya Toshniwal > enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> PFA the updated patch on this. I have tried to add test cases to check >>> for different encoding database. In the test run, it will create a >>> database, fire a query for a string, check if we get the output and dro= ps >>> the database. >>> Kindly review. >>> >>> Thanks and Regards, >>> Aditya Toshniwal >>> Software Engineer | EnterpriseDB Software Solutions | Pune >>> "Don't Complain about Heat, Plant a tree" >>> >>> On Thu, May 31, 2018 at 6:42 PM, Dave Page wrote: >>> >>>> Hi >>>> >>>> On Thu, May 31, 2018 at 1:20 AM, Aditya Toshniwal >>> enterprisedb.com> wrote: >>>> >>>>> Hi Victoria/Joao, >>>>> >>>>> On Thu, May 31, 2018 at 2:06 AM, Joao De Almeida Pereira < >>>>> jdealmeidapereira@pivotal.io> wrote: >>>>> >>>>>> Hello Aditya, >>>>>> >>>>>> It looks ok and it passes CI. >>>>>> >>>>>> We have some recommendations: >>>>>> - These look like 2 different changes so they should be in separated >>>>>> commits >>>>>> >>>>> >>>>> If you are talking of set client_encoding, then its not a bug. Its a >>>>> choice given to Postgres DB user to change the encoding of the charac= ters. >>>>> Postgres will translate characters from Server Encoding to Client Enc= oding, >>>>> and will throw error like mentioned previously. This link will help b= etter >>>>> - https://www.postgresql.org/docs/10/static/multibyte.html >>>>> The actual bug was, even after changing the client encoding to >>>>> SQL_ASCII, pgAdmin4 was not able to show the output as it was failing= in >>>>> encoding by psycopg2. The patch is for resolving that. >>>>> >>>>> >>>>>> - Do we have test coverage for the bug that you are talking about? I= f >>>>>> not we should, to ensure this problem does not happen again in a fut= ure >>>>>> change. >>>>>> >>>>> >>>>> It is not possible adding test cases for encoding related stuff, as >>>>> Postgres support a lot many different types of encoding and conversio= ns >>>>> (refer above link) >>>>> >>>> >>>> I was going to ask the same thing. Per https://www.postgresql. >>>> org/docs/10/static/multibyte.html#id-1.6.10.5.7, every characterset >>>> except SQL_ASCII can be converted to UTF-8, so we only need to test th= at >>>> UTF-8 and some other charactersets besides SQL_ASCII work, and then >>>> separately that SQL_ASCII with characters known not to be in UTF-8 wor= k. >>>> >>>> >>>>> >>>>>> Thanks >>>>>> Victoria && Joao >>>>>> >>>>>> On Wed, May 30, 2018 at 3:06 AM Aditya Toshniwal >>>>> enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> >>>>>>> PFA updated patch after all the permutations, combinations for >>>>>>> encoding for SQL_ASCII database. Also fixed a small glitch for sql >>>>>>> editor connection status check. >>>>>>> >>>>>>> Please note, ERROR: invalid byte sequence for encoding "UTF8": 0xe9 >>>>>>> 0x73 is a Postgres DB error and not pgAdmin4 error. >>>>>>> >>>>>>> >>>>>>> >>>>>>> You need to change client_encoding to the appropriate. After >>>>>>> changing client_encoding using command - set client_encoding=3D'XYZ= ', it will >>>>>>> give not give error. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> Aditya Toshniwal >>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>> >>>>>>> On Wed, May 23, 2018 at 10:13 AM, Aditya Toshniwal < >>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Thank you Victoria, Anthony. >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Aditya Toshniwal >>>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>>> >>>>>>>> On Tue, May 22, 2018 at 7:15 PM, Victoria Henry >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Aditya, >>>>>>>>> >>>>>>>>> We made a minor change to make the patch so the python linter can >>>>>>>>> pass. Attached is the change we made. >>>>>>>>> Everything else looks good. >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> >>>>>>>>> Victoria & Anthony >>>>>>>>> >>>>>>>>> On Tue, May 22, 2018 at 4:46 AM Aditya Toshniwal < >>>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> PFA updated patch. Linter issues are fixed ( we dont have any >>>>>>>>>> linter setup for python :-( ) >>>>>>>>>> Regarding test cases, they run successfully on my system and the >>>>>>>>>> reason it failed for pivotal is timeout exception. I am sorry I = can't help >>>>>>>>>> with that. >>>>>>>>>> >>>>>>>>>> Traceback (most recent call last): >>>>>>>>>> File "/tmp/build/a453582b/pgadmin-repo/web/pgadmin/feature_ >>>>>>>>>> tests/keyboard_shortcut_test.py", line 52, in runTest >>>>>>>>>> self._check_shortcuts() >>>>>>>>>> File "/tmp/build/a453582b/pgadmin-repo/web/pgadmin/feature_ >>>>>>>>>> tests/keyboard_shortcut_test.py", line 77, in _check_shortcuts >>>>>>>>>> ") and contains(@class, 'open')]") >>>>>>>>>> File "/root/.pyenv/versions/pgadmin36/lib/python3.6/site- >>>>>>>>>> packages/selenium/webdriver/support/wait.py", line 80, in until >>>>>>>>>> raise TimeoutException(message, screen, stacktrace) >>>>>>>>>> selenium.common.exceptions.TimeoutException: Message: >>>>>>>>>> >>>>>>>>>> Thanks and Regards, >>>>>>>>>> Aditya Toshniwal >>>>>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>>>>> >>>>>>>>>> On Tue, May 22, 2018 at 1:37 PM, Dave Page >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> Pivotal's buildbot is showing problems with this patch: >>>>>>>>>>> >>>>>>>>>>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/ >>>>>>>>>>> pipelines/pgadmin-patch/jobs/run-linter/builds/66 (linter >>>>>>>>>>> failed) >>>>>>>>>>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/ >>>>>>>>>>> pipelines/pgadmin-patch/jobs/run-tests/builds/84 (tests failed) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, May 22, 2018 at 7:05 AM, Aditya Toshniwal < >>>>>>>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Hackers, >>>>>>>>>>>> >>>>>>>>>>>> PFA patch for RM#3289 where decode error was thrown on queryin= g >>>>>>>>>>>> a SQL_ASCII database table. Please note, this problem occurs o= nly on >>>>>>>>>>>> windows. >>>>>>>>>>>> Sample insert - insert into test_tab values ('=C3=A9'); >>>>>>>>>>>> >>>>>>>>>>>> psycopg2 has a encodings dictionary where Postgres Database >>>>>>>>>>>> Encodings are mapped to python equivalent. It uses 'ascii' dec= oder of >>>>>>>>>>>> python to decode for SQL_ASCII encoding. If data has character= s beyond the >>>>>>>>>>>> limit of ascii then it failed. The solution would be to use ut= f_8 decoder >>>>>>>>>>>> instead of ascii. I tried setting the client_encoding using >>>>>>>>>>>> set_client_encoding('UTF8') method of a psycopg2 connection bu= t no luck >>>>>>>>>>>> (also its not allowed for async connection). I also tried exec= uting "SET >>>>>>>>>>>> CLIENT_ENCODING=3D'UTF8'" but it didn't work too. >>>>>>>>>>>> So, as in the patch, I had to set encodings dict value directl= y >>>>>>>>>>>> to 'utf_8' and it seems to be working. Please note, the same i= s added to >>>>>>>>>>>> psycopg3 milestones >>>>>>>>>>>> https://github.com/psycopg/psycopg2/milestone/4 >>>>>>>>>>>> >>>>>>>>>>>> Also fixed a small glitch for sql editor connection status >>>>>>>>>>>> check. >>>>>>>>>>>> >>>>>>>>>>>> Kindly review. >>>>>>>>>>>> >>>>>>>>>>>> Thanks and Regards, >>>>>>>>>>>> Aditya Toshniwal >>>>>>>>>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>>>>>>>>> "Don't Complain about Heat, Plant a tree" >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dave Page >>>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>>> Twitter: @pgsnake >>>>>>>>>>> >>>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>>> >>>> -- >>>> Dave Page >>>> Blog: http://pgsnake.blogspot.com >>>> Twitter: @pgsnake >>>> >>>> EnterpriseDB UK: http://www.enterprisedb.com >>>> The Enterprise PostgreSQL Company >>>> >>> >>> >> --0000000000002bbab2056dd3a520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victoria/Joao,

There is no change re= lated to notifications in this patch.=C2=A0
The below code is min= or fix related to connection status of sql editor. Can you please share the= code snippet if it is not the below.

-=C2=A0= =C2=A0 =C2=A0 =C2=A0 # Check for the asynchronous notifies statements.
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 conn.check_notifies(True)
-= =C2=A0 =C2=A0 =C2=A0 =C2=A0 notifies =3D conn.get_notifies()
+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 if status is not None:
+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Check for the asynchronous notifies statement= s.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conn.check_notifies= (True)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 notifies =3D co= nn.get_notifies()

The test cases work perfec= tly fine on my machine. I will try if I can simulate the failure on some ot= her machines.


Thanks and Regards,
Aditya Toshniwal
=
Software Engineer |=C2=A0E= nterpriseDB Software Solutions |=C2=A0P= une
"Don't Complai= n about Heat, Plant a tree"

On Mon, Jun 4, 2018 at 8:54 PM, Joao De Alme= ida Pereira <jdealmeidapereira@pivotal.io> wrote:=
Hi Aditya,
Looks li= ke there are changes in this patch that are related to notifications, these= should go into a separate commit as they are not related to encoding.

Thanks
Victoria && Jo= ao

On Mon, Jun 4, 2018 at 5:55 AM Aditya Toshniwal = <= aditya.toshniwal@enterprisedb.com> wrote:
Hi Hackers,

Please i= gnore previous patch. Fixed some linter issues. PFA updated patch.

Thanks a= nd Regards,
Aditya T= oshniwal
Software Engineer |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don't Complain about Heat, Plant a tree"<= /div>

On Mon, Jun 4, 2018 at 10:53 AM, Aditya Tosh= niwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Hackers,
PFA the updated patch on this. I have tried to add test ca= ses to check for different encoding database. In the test run, it will crea= te a database, fire a query for a string, check if we get the output and dr= ops the database.
Kindly review.

Thank= s and Regards,
Adity= a Toshniwal
Software Engineer |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don't Complain about Heat, Plant a tree"

On Thu, May 31, 2018 at = 6:42 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

<= div class=3D"gmail_quote">On Thu, May 31, 2018 at 1:20 AM, Aditya Tos= hniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Victoria/Joao,

On = Thu, May 31, 2018 at 2:06 AM, Joao De Almeida Pereira <= ;jdealmei= dapereira@pivotal.io> wrote:
Hello Aditya,

It l= ooks ok and it passes CI.

We have some recommendat= ions:
- These look like 2 different changes so they should be in = separated commits
=C2=A0
If you are talking of set client_encoding, then its n= ot a bug. Its a choice given to Postgres DB user to change the encoding of = the characters. Postgres will translate characters from Server Encoding to = Client Encoding, and will throw error like mentioned previously. This link = will help better -=C2=A0https://www.postgresql= .org/docs/10/static/multibyte.html
The actual bug was, even after changing the client encoding to SQL_ASC= II, pgAdmin4 was not able to show the output as it was failing in encoding = by psycopg2. The patch is for resolving that.
=C2=A0
- Do we have test= coverage for the bug that you are talking about? If not we should, to ensu= re this problem does not happen again in a future change.

It is not possible adding test cases for = encoding related stuff, as Postgres support a lot many different types of e= ncoding and conversions (refer above link)=C2=A0

I was going to ask the same thing. Per= =C2=A0https://www.postgresql.org/docs/10/sta= tic/multibyte.html#id-1.6.10.5.7, every characterset except SQL_AS= CII can be converted to UTF-8, so we only need to test that UTF-8 and some = other charactersets besides SQL_ASCII work, and then separately that SQL_AS= CII with characters known not to be in UTF-8 work.
=C2=A0
=
Thanks
Victoria && Joao
=

On Wed, May 30, 2018 at 3:06 AM Aditya Toshn= iwal <aditya.toshniwal@enterprisedb.com> wrote:
=
Hi Hackers,

PFA updated patch after all the permutations, combinations for encoding = for SQL_ASCII database.=C2=A0 Also fixed a small glitch for sql editor connect= ion status check.

Please note,=C2=A0ERROR: invalid byte sequence fo= r encoding "UTF8": 0xe9 0x73 is a Postgres DB error and not pgAdm= in4 error.

<Image Deleted>
=

= You need to change client_encoding to the appropriate. After changing clien= t_encoding using command - set client_encoding=3D'XYZ', it will giv= e not give error.

<Image Deleted>

Thanks and Regards,Aditya Toshniwal
Software Enginee= r |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don&#= 39;t Complain about Heat, Plant a tree"

On Wed, May 23, 2018 at 10:13 AM, Aditya Tos= hniwal <aditya.toshniwal@enterprisedb.com> wrote:
Thank you Victoria, Anthony.
Thanks and Reg= ards,
Aditya Toshniw= al
Soft= ware Engineer |=C2=A0EnterpriseDB Software Solutions |=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:"trebuchet ms",sans-se= rif;font-size:small">Pune
&= quot;Don't Complain about Heat, Plant a tree"
<= /div>

On Tue, May 22, 2018 at 7:15 PM, Victoria Henry <vhenry@= pivotal.io> wrote:
Hi Aditya,

We made a minor c= hange to make the patch so the python linter can pass.=C2=A0 Attached is th= e change we made.
Everything else looks good.

Sincerely,

Victoria & Anthony
<= div class=3D"m_-630829982078581690m_-4982701573208100365m_-4541529219916930= 722m_5579943181099405531m_-571201162196806755gmail-m_-9019081956268395818m_= -7389465867613098911m_-6881148673904556785m_-4282663695819898292h5">
On Tue, May 22, 2018 at 4:46 AM Ad= itya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi,
PFA updated patch. Linter issues are fixed ( we dont have= any linter setup for python :-( )
Regarding test cases, they run= successfully on my system and the reason it failed for pivotal is timeout = exception. I am sorry I can't help with that.

Trace= back (most recent call last):
=C2=A0 File "/tmp/build/a453582b/pgad= min-repo/web/pgadmin/feature_tests/keyboard_shortcut_test.py= ", line 52, in runTest
=C2=A0 =C2=A0 self._check_shortcuts()
=C2= =A0 File "/tmp/build/a453582b/pgadmin-repo/web/pgadmin/feature_tests/keyboard_shortcut_test.py", line 77, in _check_shortcuts=
=C2=A0 =C2=A0 ") and contains(@class, 'open')]")
= =C2=A0 File "/root/.pyenv/versions/pgadmin36/lib/python3.6/site-<= wbr>packages/selenium/webdriver/support/wait.py", line 80, in unt= il
=C2=A0 =C2=A0 raise TimeoutException(message, screen, stacktrace)
= selenium.common.exceptions.TimeoutException: Message:

Thanks and Regards,<= div>Aditya Toshniwal
Software Enginee= r |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"Don&#= 39;t Complain about Heat, Plant a tree"

On Tue, May 22, 2018 at 1:37 PM, Dave Page <= span dir=3D"ltr"><dpage@pgadmin.org> wrote:
=

On Tue,= May 22, 2018 at 7:05 AM, Aditya Toshniwal <aditya.toshniw= al@enterprisedb.com> wrote:
Hi Hackers,

PFA patch for RM#3289 where decode error was thrown on querying a = SQL_ASCII database table. Please note, this problem occurs only on windows.=
Sample insert -=C2=A0insert into test_tab values ('=C3=A9= 9;);

psycopg2 has a encodings dictionary where Pos= tgres Database Encodings are mapped to python equivalent. It uses 'asci= i' decoder of python to decode for SQL_ASCII encoding. If data has char= acters beyond the limit of ascii then it failed. The solution would be to u= se utf_8 decoder instead of ascii. I tried setting the client_encoding usin= g set_client_encoding('UTF8') method of a psycopg2 connection but n= o luck (also its not allowed for async connection). I also tried executing = "SET CLIENT_ENCODING=3D'UTF8'" but it didn't work too= .
So, as in the patch, I had to set encodings dict value directly= to 'utf_8' and it seems to be working. Please note, the same is ad= ded to psycopg3 milestones

Also fixed a small glitch fo= r sql editor connection status check.

Kindly revie= w.

Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0EnterpriseDB Software Solutions = |=C2=A0Pune
"Don't Complain about Heat, Plant a tree"= ;



--
Dave PageBlog: http://pgs= nake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.= com
The Enterprise PostgreSQL Company







--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnak= e

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Compa= ny



--0000000000002bbab2056dd3a520--