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 1fW1sM-00089w-MI for pgadmin-hackers@arkaria.postgresql.org; Thu, 21 Jun 2018 15:51:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fW1sH-0004gB-Rh for pgadmin-hackers@arkaria.postgresql.org; Thu, 21 Jun 2018 15:51:53 +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 1fW1sH-0004g4-GY for pgadmin-hackers@lists.postgresql.org; Thu, 21 Jun 2018 15:51:53 +0000 Received: from mail-lf0-x242.google.com ([2a00:1450:4010:c07::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fW1sC-0004ET-AD for pgadmin-hackers@postgresql.org; Thu, 21 Jun 2018 15:51:52 +0000 Received: by mail-lf0-x242.google.com with SMTP id i83-v6so5040442lfh.5 for ; Thu, 21 Jun 2018 08:51:47 -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=ysIUGeWs68PGkyJn/VhBNi6wtyCb3aFjOP5utGJPN60=; b=a8pIcaRzaPhIQFxsPvGnG8c5fYpGwH31/AMmR96oJ0qQrnWN6IdZQ3Omir7CY25Jqz VE4IMmZAftdD3OQy813ysfI0dpkevjaV+tZul1lRa/wIdShzX5WmwI74kDIAnNuoAl3Y 5+HGS4GVjtHWCgUY6DcwNEhoo5Gt/YHn9UmCyhx8Yqyt15bIYo95UxvRqw5RfIBNPnqY bZ+7HqlXq9lM0Te1677KPqyGcDcv0c37QYIEhA/nUG6W7+jp+qrtvSIewYsKBqp5b6pw ghXH6tmWh7Lca0AQa+rV8A7yNaZJEUvRdBO/b4eHC1qlrV4Xv71B1fNWiiwxpyPs9Qxy BHzw== 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=ysIUGeWs68PGkyJn/VhBNi6wtyCb3aFjOP5utGJPN60=; b=sYKquwwJEll1egrzh8urIKeNqtEtVV3JaI+uCuXABMdscOXkT3syhLJcwFneqnqy9X 6PXza66KEM9Pk7mxrQt9vZGI02/xpJ0xIGbdeCK7eLfPz5AAk+tR10DeGbNgV6kgDTht 2wab258mIWxgxHfOb0wSkd6ah9VV61W3rn3LnetM09l9mcq8iV2kN+US1QdjSHqSDfph bk2Reo+qVf5OvrKAAnBiuXq0y+avjxVyuQpiCXmBH9FMI7ikjiXPGgdaDmoSzfLA47ub H9T5mqMNmfy/jfpPwrw4g8mD76o0FIZOPyPFvxMKTzEDhbKG2FdsfcHtlsAkyASqK++V 1rQA== X-Gm-Message-State: APt69E3vehRitfjNoyfuUM7bgsg8/PP0lvvxV/kz423uB0mXuVy9dxlz JRCRIjUJlrhiQ65u1shEjpNDceJUkZJPZe9/9P15eg== X-Google-Smtp-Source: ADUXVKIhMiNVHpR21r5h5WBBTjqoL1BNVGoypqHPmSi+6d8Y0B/SanOT7nSV6x0ZGfuixFu2L6JlAEg7i0hlf1EzJPU= X-Received: by 2002:a2e:750d:: with SMTP id q13-v6mr17108558ljc.56.1529596303926; Thu, 21 Jun 2018 08:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:7a02:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 08:51:43 -0700 (PDT) In-Reply-To: References: From: Aditya Toshniwal Date: Thu, 21 Jun 2018 21:21:43 +0530 Message-ID: Subject: Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database. To: Dave Page Cc: Joao De Almeida Pereira , pgadmin-hackers Content-Type: multipart/mixed; boundary="00000000000058ab44056f28e4b3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000058ab44056f28e4b3 Content-Type: multipart/alternative; boundary="00000000000058ab33056f28e4b1" --00000000000058ab33056f28e4b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hackers, PFA patch to make SQL ASCII related changes compatible with Python 2.6. Dictionary comprehension is not supported in Python 2.6. On Thu, Jun 21, 2018 at 6:27 PM, Dave Page wrote: > Thanks - patch applied! > > On Wed, Jun 20, 2018 at 3:17 PM, Aditya Toshniwal enterprisedb.com> wrote: > >> Hi Dave, >> >> Attached is the updated patch. (Playing with encodings is not at all fun >> :( ) >> >> On Tue, Jun 19, 2018 at 2:23 AM, Dave Page wrote: >> >>> Hi >>> >>> On Mon, Jun 18, 2018 at 2:14 PM, Aditya Toshniwal < >>> aditya.toshniwal@enterprisedb.com> wrote: >>> >>>> Hi Hackers, >>>> >>>> Attached is the updated patch which includes the fix for Download CSV >>>> fail in SQL_ASCII database, which is RM3250 >>>> >>>> This should fix RM3289 and RM3250. As they interrelated, sending the >>>> combined patch. >>>> Kindly review. >>>> >>> >>> This is definitely looking better - both view and save now work as >>> expected. However, using the test data the I posted upthread, if I try = to >>> edit a value (in this case by adding a couple of chars to the end of th= e >>> data in row 2) I get: >>> >> It should fix the error. >> >>> >>> 2018-06-18 16:41:40,895: SQL pgadmin: Execute (void) for server #1 - >>> DB:ascii (Query-id: 3093186): >>> UPDATE public.ascii SET >>> data =3D %(data)s::text WHERE >>> id =3D '2'; >>> 2018-06-18 16:41:41,027: INFO werkzeug: 127.0.0.1 - - [18/Jun/2018 >>> 16:41:41] "POST /sqleditor/save/2805058 HTTP/1.1" 500 - >>> 2018-06-18 16:41:41,042: ERROR werkzeug: Error on request: >>> Traceback (most recent call last): >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= werkzeug/serving.py", >>> line 270, in run_wsgi >>> execute(self.server.app) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= werkzeug/serving.py", >>> line 258, in execute >>> application_iter =3D app(environ, start_response) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1997, in __call__ >>> return self.wsgi_app(environ, start_response) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1985, in wsgi_app >>> response =3D self.handle_exception(e) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1540, in handle_exception >>> reraise(exc_type, exc_value, tb) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1982, in wsgi_app >>> response =3D self.full_dispatch_request() >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1614, in full_dispatch_request >>> rv =3D self.handle_user_exception(e) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1517, in handle_user_exception >>> reraise(exc_type, exc_value, tb) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1612, in full_dispatch_request >>> rv =3D self.dispatch_request() >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask/app.py", >>> line 1598, in dispatch_request >>> return self.view_functions[rule.endpoint](**req.view_args) >>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= flask_login.py", >>> line 792, in decorated_view >>> return func(*args, **kwargs) >>> File "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/__init__.= py", >>> line 776, in save >>> default_conn) >>> File "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/command.p= y", >>> line 829, in save >>> item['sql'], item['data']) >>> File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/con= nection.py", >>> line 975, in execute_void >>> self.__internal_blocking_execute(cur, query, params) >>> File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/con= nection.py", >>> line 629, in __internal_blocking_execute >>> cur.execute(query, params) >>> File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/cur= sor.py", >>> line 176, in execute >>> return _cursor.execute(self, query, params) >>> UnicodeEncodeError: 'ascii' codec can't encode characters in position >>> 19-21: ordinal not in range(128) >>> >>> >>>> >>>> On Fri, Jun 15, 2018 at 2:33 PM, Aditya Toshniwal < >>>> aditya.toshniwal@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Fri, Jun 15, 2018 at 2:08 PM, Dave Page wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Thu, Jun 14, 2018 at 7:05 AM, Aditya Toshniwal < >>>>>> aditya.toshniwal@enterprisedb.com> wrote: >>>>>> >>>>>>> I am sorry I missed the attachment. :( >>>>>>> PFA. >>>>>>> >>>>>> >>>>>> It looks like the encoding names are getting munged somewhere. I see >>>>>> you've accounted for that to some degree in connection.py (you have = both >>>>>> SQL_ASCII/MULE_INTERNAL and SQLASCII/MULEINTERNAL), however it doesn= 't seem >>>>>> to be enough as I'm getting the following error when trying to downl= oad CSV >>>>>> from the query tool. Can we ensure that conn.encoding contains an un= -munged >>>>>> value at all times, or is that coming from psycopg2? >>>>>> >>>>> =E2=80=8BThat is done by pyscopg2 and conn.encoding is a psycopg2 con= nection >>>>> property.=E2=80=8B >>>>> >>>>> >>>>>> >>>>>> 2018-06-15 09:32:28,799: INFO werkzeug: 127.0.0.1 - - [15/Jun/2018 >>>>>> 09:32:28] "GET /sqleditor/query_tool/download >>>>>> /2732923?query=3DSELECT%20*%20FROM%20public.sql_ascii%0AORDER% >>>>>> 20BY%20id%20ASC%20&filename=3Dsql_ascii.csv HTTP/1.1" 500 - >>>>>> 2018-06-15 09:32:28,801: ERROR werkzeug: Error on request: >>>>>> Traceback (most recent call last): >>>>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packag= es/werkzeug/serving.py", >>>>>> line 270, in run_wsgi >>>>>> execute(self.server.app) >>>>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packag= es/werkzeug/serving.py", >>>>>> line 260, in execute >>>>>> for data in application_iter: >>>>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packag= es/werkzeug/wsgi.py", >>>>>> line 870, in __next__ >>>>>> return self._next() >>>>>> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packag= es/werkzeug/wrappers.py", >>>>>> line 82, in _iter_encoded >>>>>> for item in iterable: >>>>>> File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/= connection.py", >>>>>> line 752, in gen >>>>>> column_name =3D column_name.decode(conn_encoding) >>>>>> LookupError: unknown encoding: SQLASCII >>>>>> >>>>> >>>>> =E2=80=8BThis is because there is code bug here. Below is code used t= o decode >>>>> a column name. Connection encoding and python encoding are two differ= ent >>>>> things. Python does not know what SQLASCII is. This will work with UT= F-8 >>>>> because python has decoder with same name. I tried to download CSV wi= th the >>>>> original code without changes and it fails there too. I will fix this= and >>>>> will send the updated patch. I should have checked this. >>>>> conn_encoding =3D cur.connection.encoding >>>>> column_name =3D column_name.decode(conn_encoding)=E2=80=8B >>>>> >>>>> >>>>>> >>>>>> -- >>>>>> Dave Page >>>>>> Blog: http://pgsnake.blogspot.com >>>>>> Twitter: @pgsnake >>>>>> >>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>> The Enterprise PostgreSQL Company >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Aditya Toshniwal >>>>> Software Engineer | EnterpriseDB Software Solutions | Pune >>>>> "Don't Complain about Heat, Plant a tree" >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> 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 > --=20 Thanks and Regards, Aditya Toshniwal Software Engineer | EnterpriseDB Software Solutions | Pune "Don't Complain about Heat, Plant a tree" --00000000000058ab33056f28e4b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hackers,

PFA patch to make SQL ASCII related changes co= mpatible with Python 2.6. Dictionary comprehension is not supported in Pyth= on 2.6.

On Thu, Jun 21, 2018 at 6:27 PM, Dave Page <dpage@pgadmin.org> wrote:
Thanks - pa= tch applied!

On Wed, Jun 20, 2018 at 3:17 PM, A= ditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi Dave,<= /div>
=
Attached is the updated patch. (Playing with encodings is not at all f= un :( )

On Tue, Jun 19, 2018 at 2:23 AM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On = Mon, Jun 18, 2018 at 2:14 PM, Aditya Toshniwal <aditya.tos= hniwal@enterprisedb.com> wrote:
Hi Hackers,

Attached is th= e updated patch which includes the fix for Download CSV fail in SQL_ASCII d= atabase, which is RM3250=C2=A0
This should fix RM3289 and RM3250. As they interrelated, sending t= he combined patch.
Kindl= y review.

This is defini= tely looking better - both view and save now work as expected. However, usi= ng the test data the I posted upthread, if I try to edit a value (in this c= ase by adding a couple of chars to the end of the data in row 2) I get:
It should fix the error.=C2=A0=C2=A0

2018-06-18 16:41:40,895: SQL pgadmin: Execute (vo= id) for server #1 - DB:ascii (Query-id: 3093186):
UPDATE public.a= scii SET
data =3D %(data)s::text WHERE
id =3D '2= 9;;
2018-06-18 16:41:41,027: INFO werkzeug: 127.0.0.= 1 - - [18/Jun/2018 16:41:41] "POST /sqleditor/save/2805058 HTTP/1.1&qu= ot; 500 -
2018-06-18 16:41:41,042: ERROR werkzeug: E= rror on request:
Traceback (most recent call last):
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/= site-packages/werkzeug/serving.py", line 270, in run_wsgi
=C2=A0 =C2=A0 execute(self.server.app)
=C2=A0 File &quo= t;/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/= werkzeug/serving.py", line 258, in execute
=C2=A0 =C2=A0 app= lication_iter =3D app(environ, start_response)
=C2=A0 File = "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packa= ges/flask/app.py", line 1997, in __call__
=C2=A0 =C2=A0 retu= rn self.wsgi_app(environ, start_response)
=C2=A0 File "/User= s/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/a= pp.py", line 1985, in wsgi_app
=C2=A0 =C2=A0 response =3D se= lf.handle_exception(e)
=C2=A0 File "/Users/dpage/.virtualenv= s/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1= 540, in handle_exception
=C2=A0 =C2=A0 reraise(exc_type, exc_valu= e, tb)
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/= lib/python2.7/site-packages/flask/app.py", line 1982, in wsgi_app=
=C2=A0 =C2=A0 response =3D self.full_dispatch_request()
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/s= ite-packages/flask/app.py", line 1614, in full_dispatch_request
=C2=A0 =C2=A0 rv =3D self.handle_user_exception(e)
=C2= =A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-p= ackages/flask/app.py", line 1517, in handle_user_exception
<= div>=C2=A0 =C2=A0 reraise(exc_type, exc_value, tb)
=C2=A0 File &q= uot;/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-package= s/flask/app.py", line 1612, in full_dispatch_request
=C2=A0 = =C2=A0 rv =3D self.dispatch_request()
=C2=A0 File "/Users/dp= age/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.p= y", line 1598, in dispatch_request
=C2=A0 =C2=A0 return self= .view_functions[rule.endpoint](**req.view_args)
=C2=A0 File = "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packa= ges/flask_login.py", line 792, in decorated_view
=C2=A0 =C2= =A0 return func(*args, **kwargs)
=C2=A0 File "/Users/= dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/__init__.py",= line 776, in save
=C2=A0 =C2=A0 default_conn)
=C2=A0 F= ile "/Users/dpage/git/pgadmin4/web/pgadmin/tools/sqleditor/comma<= wbr>nd.py", line 829, in save
=C2=A0 =C2=A0 item['sql= 9;], item['data'])
=C2=A0 File "/Users/dpage/git/pga= dmin4/web/pgadmin/utils/driver/psycopg2/connection.py", line= 975, in execute_void
=C2=A0 =C2=A0 self.__internal_blocking_exec= ute(cur, query, params)
=C2=A0 File "/Users/dpage/git/p= gadmin4/web/pgadmin/utils/driver/psycopg2/connection.py", li= ne 629, in __internal_blocking_execute
=C2=A0 =C2=A0 cur.execute(= query, params)
=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/cursor.py", line 176, in execute=
=C2=A0 =C2=A0 return _cursor.execute(self, query, params)
<= div>UnicodeEncodeError: 'ascii' codec can't encode characters i= n position 19-21: ordinal not in range(128)
=C2=A0

On Fri, Jun 15, 2018 at 2:3= 3 PM, Aditya Toshniwal <aditya.toshniwal@enterprisedb= .com> wrote:
Hi Dave= ,

On F= ri, Jun 15, 2018 at 2:08 PM, Dave Page <dpage@pgadmin.org> w= rote:
Hi

On Thu, Jun 14, 2018 at= 7:05 AM, Aditya Toshniwal <aditya.toshniwal@enterprisedb<= wbr>.com> wrote:
I am sorry I missed the attachment. :(
PFA.=

It looks like the encod= ing names are getting munged somewhere. I see you've accounted for that= to some degree in connection.py (you have both SQL_ASCII/MULE_INTERNAL and= SQLASCII/MULEINTERNAL), however it doesn't seem to be enough as I'= m getting the following error when trying to download CSV from the query to= ol. Can we ensure that conn.encoding contains an un-munged value at all tim= es, or is that coming from psycopg2?
=E2=80=8BThat is done by pyscopg2 and conn.encoding is a psycopg2 connect= ion property.=E2=80=8B
=C2=A0

2018-06-15 09:32:28,799: INF= O werkzeug: 127.0.0.1 - - [15/Jun/2018 09:32:28] "GET /sq= leditor/query_tool/download/2732923?query=3DSELECT%20*%20FROM%20p= ublic.sql_ascii%0AORDER%20BY%20id%20ASC%20&filename=3Dsql_asc= ii.csv HTTP/1.1" 500 -
2018-06-15 09:32:28,801: ERROR werkzeug: Error on request:
Traceback (most recent call last):
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/pytho= n2.7/site-packages/werkzeug/serving.py", line 270, in run_wsgi
=C2=A0 =C2=A0 execute(self.server.app)
=C2=A0 File "= /Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/we= rkzeug/serving.py", line 260, in execute
=C2=A0 =C2=A0 for d= ata in application_iter:
=C2=A0 File "/Users/dpage/.virtuale= nvs/pgadmin4/lib/python2.7/site-packages/werkzeug/wsgi.py", = line 870, in __next__
=C2=A0 =C2=A0 return self._next()
=C2=A0 File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/si= te-packages/werkzeug/wrappers.py", line 82, in _iter_encoded
=C2=A0 =C2=A0 for item in iterable:
=C2=A0 File "/User= s/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/connection= .py", line 752, in gen
=C2=A0 =C2=A0 column_name =3D column_= name.decode(conn_encoding)
LookupError: unknown encoding: SQ= LASCII
=C2=A0
=E2= =80=8BThis is because there is code bug here. Below is code used to decode = a column name. Connection encoding and python encoding are two different th= ings. Python does not know what SQLASCII is. This will work with UTF-8 beca= use python has decoder with same name. I tried to download CSV with the ori= ginal code without changes and it fails there too. I will fix this and will= send the updated patch. I should have checked this.
conn_encoding =3D cu= r.connection.encoding
column_name =3D column_name.decode(conn_encodi= ng)=E2=80=8B
=C2=A0

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0EnterpriseDB= Software Solutions |=C2=A0Pune<= /div>
"Don't Complain about Hea= t, Plant a tree"



--
Thank= s and Regards,
Adity= a Toshniwal
Software Engineer |=C2=A0EnterpriseDB Software Solutions |=C2=A0Pune
"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 Compan= y
=


--
Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0Enter= priseDB Software Solutions |=C2=A0Pune<= /span>
"Don't Complain ab= out Heat, Plant a tree"



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

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



--
=
Thanks and Regards,
Aditya Toshniwal
Software Engineer |=C2=A0EnterpriseDB So= ftware Solutions |=C2=A0Pune
"Don't Complain about Heat, = Plant a tree"
--00000000000058ab33056f28e4b1-- --00000000000058ab44056f28e4b3 Content-Type: application/octet-stream; name="RM3289_py26.patch" Content-Disposition: attachment; filename="RM3289_py26.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jioq4u230 ZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL3V0aWxzL2RyaXZlci9wc3ljb3BnMi9jb25uZWN0aW9u LnB5IGIvd2ViL3BnYWRtaW4vdXRpbHMvZHJpdmVyL3BzeWNvcGcyL2Nvbm5lY3Rpb24ucHkKaW5k ZXggZThlZDg4YTMuLjFiNGQyYTNmIDEwMDY0NAotLS0gYS93ZWIvcGdhZG1pbi91dGlscy9kcml2 ZXIvcHN5Y29wZzIvY29ubmVjdGlvbi5weQorKysgYi93ZWIvcGdhZG1pbi91dGlscy9kcml2ZXIv cHN5Y29wZzIvY29ubmVjdGlvbi5weQpAQCAtNjIyLDE0ICs2MjIsMTUgQEAgV0hFUkUKICAgICAg ICAgIyBXZSBuZWVkIHRvIGVzYWNwZSB0aGUgZGF0YSBzbyB0aGF0IGl0IGRvZXMgbm90IGZhaWwg d2hlbgogICAgICAgICAjIGl0IGlzIGVuY29kZWQgd2l0aCBweXRob24gYXNjaWkKICAgICAgICAg IyB1bmljb2RlX2VzY2FwZSBoZWxwcyBpbiBlc2NhcGluZyBhbmQgdW5lc2NhcGluZwotICAgICAg ICBpZiBzZWxmLmNvbm4uZW5jb2RpbmcgaW4gKCdTUUxfQVNDSUknLCAnU1FMQVNDSUknLAotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdNVUxFX0lOVEVSTkFMJywgJ01VTEVJTlRF Uk5BTCcpXAotICAgICAgICAgICBhbmQgcGFyYW1zIGlzIG5vdCBOb25lIGFuZCB0eXBlKHBhcmFt cykgPT0gZGljdDoKLSAgICAgICAgICAgICAgICBwYXJhbXMgPSB7Ci0gICAgICAgICAgICAgICAg ICAgIGtleTogdmFsLmVuY29kZSgndW5pY29kZV9lc2NhcGUnKQotICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC5kZWNvZGUoJ3Jhd191bmljb2RlX2VzY2FwZScpCi0gICAgICAgICAgICAgICAg ICAgIGZvciBrZXksIHZhbCBpbiBwYXJhbXMuaXRlbXMoKQotICAgICAgICAgICAgICAgIH0KKyAg ICAgICAgaWYgc2VsZi5jb25uOgorICAgICAgICAgICAgaWYgc2VsZi5jb25uLmVuY29kaW5nIGlu ICgnU1FMX0FTQ0lJJywgJ1NRTEFTQ0lJJywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJ01VTEVfSU5URVJOQUwnLCAnTVVMRUlOVEVSTkFMJylcCisgICAgICAgICAgICAg ICBhbmQgcGFyYW1zIGlzIG5vdCBOb25lIGFuZCB0eXBlKHBhcmFtcykgPT0gZGljdDoKKyAgICAg ICAgICAgICAgICAgICAgcGFyYW1zID0gZGljdCgKKyAgICAgICAgICAgICAgICAgICAgICAgIChr ZXksIHZhbC5lbmNvZGUoJ3VuaWNvZGVfZXNjYXBlJykKKyAgICAgICAgICAgICAgICAgICAgICAg ICAuZGVjb2RlKCdyYXdfdW5pY29kZV9lc2NhcGUnKSkKKyAgICAgICAgICAgICAgICAgICAgICAg IGZvciBrZXksIHZhbCBpbiBwYXJhbXMuaXRlbXMoKQorICAgICAgICAgICAgICAgICAgICApCiAg ICAgICAgIHJldHVybiBwYXJhbXMKIAogICAgIGRlZiBfX2ludGVybmFsX2Jsb2NraW5nX2V4ZWN1 dGUoc2VsZiwgY3VyLCBxdWVyeSwgcGFyYW1zKToK --00000000000058ab44056f28e4b3--