bpo-16379: Expose sqlite error code

[palaviv]

This PR adds the sqlite error code and name to the exceptions raised by the sqlite3 module. Once this is merged my hope is to expose the sqlite extended error code as discussed in bpo-24139

https://bugs.python.org/issue16379

[auvipy]

plz rebase!

[matrixise]

Hi @palaviv

Would you be interested to upgrade your PR to the last master?

Thank you

[palaviv]

Sure @matrixise. Do you think there is a chance for this to be merged?

[dimaqq]

If I remember https://bugs.python.org/issue24139 correctly, the issue was rather about exposing the extended error codes http://www.sqlite.org/c3ref/c_abort_rollback.html

[palaviv]

@dimaqq you are correct. This is a patch for https://bugs.python.org/issue16379. There is a different patch that depends on this change to solve https://bugs.python.org/issue24139.

[danielepusceddu]

I'd really really like to have this feature...

[dimaqq]

It looks like SQLITE_OK is used in the wild (https://github.com/search?l=Python&p=4&q=SQLITE_OK&type=Code) thus it cannot be removed.

[erlend-aasland]

SQLITE_OK is definitely in use. For example, it is used one of the valid return values in authoriser callbacks.

[danielshahaf]

Hi @palaviv, thanks for picking this up. Should SQLITE_NOTICE and SQLITE_WARNING be added to this list?

[erlend-aasland]

@palaviv: Can you rebase onto master and update your code to PEP 7 standards? Also, the #ifdefs are not needed as SQLite 3.7.15 is now a hard requirement.

[erlend-aasland]

@palaviv, are you planning on landing this PR? If not, would you mind if I reopened a PR with your changes cherry-picked onto it?

[erlend-aasland]

Closing this, as #27786 (based off of this PR) has now been merged. Thank you for your work, @palaviv!