Re: psycopg2.Error.pgerror encoding ?

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

In response to

Browse psycopg by date

  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 ?