Re: Plans for 2.8 - Mailing list psycopg

From Rory Campbell-Lange
Subject Re: Plans for 2.8
Date
Msg-id 20181004135501.2rvzcg3li4plo77b@campbell-lange.net
Whole thread Raw
In response to Plans for 2.8  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List psycopg
On 04/10/18, Daniele Varrazzo (daniele.varrazzo@gmail.com) wrote:
> The feature I'm the most excited about (and worried about its
> reception) is to raise a different exception for every postgres error
> message (see #682) . For instance `SELECT * FROM wrong_name` will
> raise `UndefinedTable` rather than `ProgrammingError`. Currently
> handling a specific exception requires catching a broader class and
> looking at the pgcode:
> 
>     try:
>         cur.execute("lock table %s in access exclusive mode nowait" % name)
>     except psycopg2.OperationalError as e:
>         if e.pgcode == psycopg2.errorcodes.LOCK_NOT_AVAILABLE:
>             locked = True
>         else:
>             raise
> 
> This can become a much more natural:
> 
>     try:
>         cur.execute("lock table %s in access exclusive mode nowait" % name)
>     except psycopg2.errors.LockNotAvailable:
>             locked = True
> 
> The error classes are generated automatically from Postgres source
> code and are subclasses of the previously existing ones, so existing
> code should be unaffected. I'd be happy to have input about the
> feature and suggestions before releasing it.

Hi Daniele

The greater depth of exception reporting looks great to me, particularly
if they are subclasses of the existing ones.

Regards
Rory


psycopg by date:

Previous
From: Federico Di Gregorio
Date:
Subject: Re: Plans for 2.8
Next
From: Daniele Varrazzo
Date:
Subject: Re: Plans for 2.8