| 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: | Whole Thread | Raw Message | 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 ? |