Plans for 2.8 - Mailing list psycopg

Hello,

next week I will have some time and maybe could end all the work to
release psycopg 2.8. I am aware there are several features which have
been awaiting for some time. The state of the work can be seen in [1].

[1] https://github.com/psycopg/psycopg2/issues?q=milestone%3A"psycopg+2.8"

Psycopg 2.8 will only support Python 2.7 and 3.4+. The codebase has
been heavily hammered by Jon Dufresne who has killed a lot of Py2isms
and the whole use of 2to3 is now replaced by a minimal compatibility
module. So Python is now as modern as C in supporting both 2 and 3
with a single codebase :P Other deprecated and unused objects have
also been dropped, see the news file [2]. Fog, if you can take a look
at examples/sandbox and delete what's no more required there (#645),
that would be great :)

[2] https://github.com/psycopg/psycopg2/blob/master/NEWS

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.

A tiny improvement to SQL generation is already ready^W merged in
#732: it will be possible to use `Identifier("schema", "name")` which
would be rendered in dotted notation in the query. Currently
`Identifier()` takes a single param so this extension is backward
compatible and there is no need to introduce a new `Composable` type
to represent dotted sequences of identifiers.

There are requests to get extra info about the connection or the
result (see #726, #661). They are reasonable and not too difficult to
implement so I'd like to give them a go. However they are easy enough
for someone to contribute if you feel? That would be very appreciated
and would reduce the surface of the works to perform on my part.
Another tiny feature would be to support IntEnum out-of-the-box
(#591), which I've never used in Python.

In the other thread these days we have discussed about introducing
capsules: we can take a look to that too... Added #782.

Thank you very much for any contribution, with ideas and even more with code :)

-- Daniele