ODBC est utile si vous voulez un adaptateur standard qui utilise une API similaire pour différentes bases de données. Personnellement, je pense que c'est une API horrible, mais elle est largement comprise et bien documentée.
libpq communique plus directement avec PostgreSQL. Vous pouvez obtenir de meilleures performances avec, mais probablement pas assez pour que cela fasse une différence pour la plupart des applications, qui passent du temps sur l'exécution des requêtes, la latence du réseau, etc., pas dans la bibliothèque cliente.
Les nouvelles versions de psqlODBC sont construites sur libpq et servent de wrapper ODBC pour libpq.
Il y a aussi libdbi, qui offre une API moins horrible qu'ODBC.
Pour être complet, il y a aussi le SPI serveur-backend, qui peut être utilisé par des fonctions définies par l'utilisateur écrites en C et chargées dans le serveur PostgreSQL. Ce n'est pas utile en dehors des extensions et des fonctions du serveur.
Oh, et il y a ecpg. N'utilisez pas ecpg. Il s'agit d'un outil SQL intégré au langage super hérité qui existe principalement pour faciliter le portage à partir de certains autres moteurs de base de données. N'utilisez pas ecpg. Vraiment.
Pour C++, il y a l'interface QtSQL (exceptionnellement pour Qt, c'est affreux et douloureusement limité, ne l'utilisez pas) et libpq++ (OK mais en grande partie non maintenu).
Personnellement, j'écris du code libpq directement, mais c'est parce que je travaille sur du code qui va généralement dans PostgreSQL lui-même. Si vous ne pouvez pas imaginer vouloir cibler quoi que ce soit d'autre que PostgreSQL, vous voudrez peut-être écrire du code libpq; sinon, utilisez probablement ODBC avec psqlODBC.
