From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org> |
Subject: | Re: psycopg2.Error.pgerror encoding ? |
Date: | 2013-11-13 14:39:35 |
Message-ID: | CA+mi_8Y74f0LJ4cfG8eERanTUeZTyOXD01504AEp6tbso_cz_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On Wed, Nov 13, 2013 at 12:47 PM, Karsten Hilbert
<Karsten(dot)Hilbert(at)gmx(dot)net> wrote:
> On Wed, Nov 13, 2013 at 10:26:30AM +0000, Daniele Varrazzo wrote:
>
>> > I have a simple (?) question regarding psycopg2.Error
>> >
>> > http://initd.org/psycopg/docs/module.html#exceptions
>> >
>> > Which encoding is the string attribute .pgerror
>> > going to be in ?
>>
>> In Python 2 it will be in the connection encoding; specifically we
>> receive the 8-bit message from the backend and we just create a Python
>> string out of that data, without re-checking the data is valid in that
>> encoding (we trust the database).
>
> In other words:
>
> unicode(exception.pgerror, exception.cursor.connection.encoding, 'replace')
>
> "should" do the "right" thing ?
Yes, it should be the right way to decode error messages,
notifications and every other string received from the database. You
should not assume exception.cursor is always present though: it's not
there if the error wasn't raised by a cursor (but e.g. by cnn.commit()
or connect()).
-- Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Luca Ferroni | 2013-11-15 08:45:09 | Server side prepared statements and executemany |
Previous Message | Karsten Hilbert | 2013-11-13 12:47:06 | Re: psycopg2.Error.pgerror encoding ? |