Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0hCl-0006Gv-Qy for pgadmin-hackers@arkaria.postgresql.org; Tue, 27 Mar 2018 05:31:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f0hCj-00013k-EB for pgadmin-hackers@arkaria.postgresql.org; Tue, 27 Mar 2018 05:31:29 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0hCi-00013a-Pr for pgadmin-hackers@lists.postgresql.org; Tue, 27 Mar 2018 05:31:29 +0000 Received: from mail-qt0-x22e.google.com ([2607:f8b0:400d:c0d::22e]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f0hCa-000467-A0 for pgadmin-hackers@postgresql.org; Tue, 27 Mar 2018 05:31:27 +0000 Received: by mail-qt0-x22e.google.com with SMTP id d18so9792050qtl.8 for ; Mon, 26 Mar 2018 22:31:19 -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=GBWHk7hx7tHehW6mwyv+tBrIe/t4jg7fQvkRysDaObI=; b=hwA06MD47qI4KNZrsw/KIv/DidXjQEov3ceCrmaD3FqXiPtpvzPkWoz8V0QnXm0ZVZ hRp/s9OFJEoSRbuVtzp8/bM9HxWpO05pqLN+HUH2CU9H0/y+fj9eGMCUbYV7MX1I6E2x f1pKbGcL0Al+JLKDOFK64FlylmF38+1k/5HWQEWSYCE51cA5PqCcH+P667JDxNcMWn2Y pdHt745cbC5/UcDrOVGrE2FyCsI3zrmzitG02Uwr/Lx9V/IVvuazu4GKfkG+2+Vtx0at qc3xOxDK5lp6hAWGi7Ps0XQPoP6In5MH3k/luefQiXwH76YubsnG/GCYSwhdwJDFKNMh bkGg== 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=GBWHk7hx7tHehW6mwyv+tBrIe/t4jg7fQvkRysDaObI=; b=IEKfwzHzTIqM7PfmrMyx9DMB9AFitMoGiAgqYwlZvvAiqOYweyZ+J83TMCNS7jcxhI cDLJ+hXEN/GjoZb3vbuFDly9vdjpFdBYEjmZ3dO5UEzoEOJVXk07g5xQpgIucSNOv+iV 6YKhdAQ5uKE23zD6lo5SPPO0DYpyaMMStg+EXRZT9BuljYxSFlUiq/QioeaJwp1teAKr LHEPlLsjBmV2d7UGY7U5W0G5RtRbQeOWy1gK5xdYNH+suTTW5SPWijdUKLVofQKNv2+s jV0xRmT6koX+2tZp6BGk+MMrWNc864VLGHWBfch+wtQTwT57e0sj66DpoEypTvF8sT2F ZroA== X-Gm-Message-State: AElRT7Hd5ZTt+NISuZONk1PlQFEjea2QEo87TkmL1IomRoVl4yZSq20p acSPewLHdiBNqvMPPJlpUoMa6KM117E4LeyS9sgIFQ== X-Google-Smtp-Source: AG47ELsC3QVpG1UbKXq5OFyS2Mv4za94FvLvQbX1PoNN1Pf7iQV/6PHzYlk4jQuLZsfy2WOfac1xDeNwzdn8FB5XXAc= X-Received: by 10.200.1.2 with SMTP id e2mr56554196qtg.121.1522128678136; Mon, 26 Mar 2018 22:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.182.1 with HTTP; Mon, 26 Mar 2018 22:31:17 -0700 (PDT) In-Reply-To: References: From: Akshay Joshi Date: Tue, 27 Mar 2018 11:01:17 +0530 Message-ID: Subject: Re: [pgAdmin4][patch]: RM #3090 pgadmin shows misleading "Query returned successfully" with incorrect SQL To: Joao De Almeida Pereira Cc: Dave Page , pgadmin-hackers Content-Type: multipart/alternative; boundary="f403045f39e429cb5205685e3332" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --f403045f39e429cb5205685e3332 Content-Type: text/plain; charset="UTF-8" Hi Joao On Tue, Mar 27, 2018 at 12:01 AM, Joao De Almeida Pereira wrote: > Hello, > We tried to reproduce the issue but we were not capable to reproduce it. > What it is strange on the fix is that python is complaining about a > different line then the one that was fixed. Maybe this is just a Python > thing.... > I have mentioned the steps in RM and I have tried it on Ubuntu 16. Python is complaining the exact line where I have fixed the logic. ex_diag_message = u"{0}: {1}".format( self.decode_to_utf8(exception_obj.diag.severity), # exception_obj.diag.severity is not decoded before my fix. self.decode_to_utf8(exception_obj.diag.message_primary) ) > > I assume that the fix works, but I would love to see some tests to ensure > it is working. Another issue that looks more problematic is the fact that, > as per the Redmine issue, when an exception is thrown it sends back a > Successful Query message. If this is the case then this fix doesn't look > like it is enough to solve the problem. > Yes it works. With the latest code I didn't see Successful Query message, it is showing "Not connected to the server .....", but the stack trace is same that was mentioned in the RM. > > Thanks > Victoria & Joao > > On Mon, Mar 26, 2018 at 9:00 AM Dave Page wrote: > >> Thanks, applied. >> >> On Mon, Mar 26, 2018 at 11:43 AM, Akshay Joshi < >> akshay.joshi@enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> Please find the attached patch to fix RM #3090 pgadmin shows misleading >>> "Query returned successfully" with incorrect SQL. >>> >>> -- >>> *Akshay Joshi* >>> >>> *Sr. Software Architect * >>> >>> >>> >>> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 >>> 976-788-8246 <+91%2097678%2088246>* >>> >> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > -- *Akshay Joshi* *Sr. Software Architect * *Phone: +91 20-3058-9517Mobile: +91 976-788-8246* --f403045f39e429cb5205685e3332 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joao

= On Tue, Mar 27, 2018 at 12:01 AM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io> wr= ote:
Hello,
We tried= to reproduce the issue but we were not capable to reproduce it.=C2=A0
What it is strange on the fix is that python is complaining about a d= ifferent line then the one that was fixed. Maybe this is just a Python thin= g....

=C2=A0 =C2=A0 I have ment= ioned the steps in RM and I have tried it on Ubuntu 16. Python is complaining the ex= act line where I have fixed the logic.=C2=A0
   ex_diag_message =3D u&qu=
ot;{0}:  {1}".format(
     self.decode_to_utf8(exception_obj.diag.severity),         # exception_ob=
j.diag.se=
verity is not decoded before my fix.
     self.decode_to_utf8(exception_obj.diag.message_primary)
   )
= =C2=A0=C2=A0

=
I assume that the fix works, but I would love to see some tests = to ensure it is working. Another issue that looks more problematic is the f= act that, as per the Redmine issue, when an exception is thrown it sends ba= ck a Successful Query message. If this is the case then this fix doesn'= t look like it is enough to solve the problem.

=C2=A0 =C2=A0 Yes it works. With the latest code I didn'= ;t see Successful Query message, it is showing "Not connected to the s= erver .....", but the stack trace is same that was mentioned in the RM= .=C2=A0 =C2=A0=C2=A0
<= div>
Thanks
Victoria & Joao

On Mon, Mar 26, 2018 at 9:00 AM Dave Page <dpage@pgadmin.org> wrote:
Thanks, applied.

On Mon, Mar 26, 2018 at 11:43 AM, Akshay Joshi &= lt;aksha= y.joshi@enterprisedb.com> wrote:
Hi Hackers,

Please find the = attached patch to fix RM=C2=A0#3090 pgadmin shows misleadin= g "Query returned successfully" with incorrect SQL.

--
Akshay Joshi=
Sr. Software Architect





--
Dave Page
Blog: http://pgsnake.blog= spot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.comThe Enterprise PostgreSQL Company



--
=
= Akshay Jo= shi
Sr. Software Architect
<= font color=3D"#3333FF">
=
=
Phone: +91 20-3058-9517
Mobil= e: +91 976-788-8246
--f403045f39e429cb5205685e3332--