Beta c'est subjectif. Ici c'est parce qu'il n'y a pas eu vraiment de stress-test sur ce code.
Sinon, pas de nouvelles fonctionnalités prévues à court terme. Ca m'intéresserait beaucoup d'intégrer libpqtypes, mais je n'ai pas assez de temps pour le faire.

Ok, voici quelques éléments de réponse:

Un inconvénient concret est qu'on ne peut pas exécuter des commandes sql sans instancier d'abord une transaction, alors que postgresql lui-même ne l'impose pas (non seulement il ne l'impose pas mais dans de rares comme CREATE DATABASE, il l'interdit. A ce jour il me semble  qu'il n'y a tjrs pas de moyen de faire un create database avec  libpqxx).
En plus le design pattern suggéré  des functors pour les transactions me parait trop loin de la logique classique d'encapsulation, et sert surtout à "résoudre" un pb (la perte de connexion), qui à mon avis est hors sujet.

La lib ne gère pas du tout le format binaire. L'intérêt du binaire est discutable pour le tout venant, mais pour les champs bytea de taille significative, c'est dommage.

D'une manière générale, le niveau d'abstraction de l'API me parait trop élevé là où ça ne m'intéresse pas vraiment et pas assez là où ça m'intéresserait.
Trop: parce que quand on connait déjà les idiomes postgresql et qu'on sait à quoi on veut arriver au niveau SQL, on se retrouve à décortiquer l'API de haut en bas pour trouver derrière quelle classe c'est caché et à quel niveau de la hiérarchie il faut opérer. Parfois c'est dur à comprendre: pour les prepared statements par exemple, la méthode pour typer les paramètres m'a paru incompréhensible, et aucun exemple ni dans la doc ni dans le tutoriel.

En revanche, peu d'abstraction pour les manipulations de données échangées entre client et serveur et la gestion de type. On utilise esc(), to_string(), from_string() pour encoder/décoder, et là on se croirait presque en C. Cette partie-là me parait décevante parce qu'on peut faire mieux en C++. Rien non plus pour gérer les tableaux ou les types composites ni en entrée ni en sortie.

C'est une bonne idée.
Sinon côté résolution peut-être tenter un REINDEX, un index corrompu pouvant mener à des incohérences entre différentes requêtes.

La représentation textuelle d'un refcursor, c'est son nom. Il se trouve que les noms générés par PG ressemblent à <unnamed portal N> mais ça n'a pas d'importance. Le programme C++ doit récupérer ce nom comme résultat de la fonction et le mettre dans la commande FETCH ALL FROM "mettre le nom ici".
Le programme C++ lui-même n'a pas à utiliser DECLARE name CURSOR FOR... car sinon ça fait double emploi avec le curseur déjà ouvert dans la fonction plgsql.

Le code 173 n'est pas le point d'exclamation, c'est un "soft hyphen".
Voir http://en.wikipedia.org/wiki/Latin1
Le point d'exclamation inversé serait plutôt 161

Et pour le passer à COPY pourquoi ne pas commençer par le plus simple: ... DELIMITER '¡' ?

Une explication possible est que par défaut les packages debian/ubuntu de postgres ont une connexion cryptée avec SSL y compris sur localhost.
Dans le cas d'un gros select * sur un réseau très rapide, a fortiori localhost, ça peut effectivement mettre 10 fois plus de temps en crypté qu'en clair pour transférer tous les résultats.
Et le temps en question ne se voit pas dans l'explain analyze.
En revanche en socket du domaine unix il n'y a jamais de cryptage, c'est précisé dans la doc de libpq.

La commande \d matable de psql, ainsi que pg_dump -s permettent de voir du point de vue de l'utilisateur sur quoi porte l'index.
En regardant là, on voit que le renommage d'une colonne est bien propagé à l'index.

La question de savoir pourquoi pg_attribute.attname n'est pas renommé pour l'index a une réponse ici:
http://archives.postgresql.org/pgsql-ha … g01398.php

Mais plus généralement il faut éviter de supposer quoi que ce soit sur les tables de pg_catalog, c'est quand même essentiellement de la tambouille interne du SGBD susceptible de changer d'une version majeure à l'autre.

Pourquoi passer par la base pour retrier une liste qui est déjà chargée dans une appli? Les composants d'affichage du genre grille ou liste ont généralement leurs propres méthodes de tri en mémoire par une colonne, visible ou non.
Par ailleurs sil y a 2 utilisateurs simultanés et qu'ils doivent voir un tri différent, l'avoir dans une colonne de la table ne peut pas convenir.

Cette séquence lgputils_numuser_seq est automatiquement créée pour la colonne SERIAL, mais sa gestion ultérieure est laissée à la charge de l'utilisateur.
Donc en parallèle au grant insert on LGPUTILS to public, il faudrait donner le droit d'utilisation à la séquence utilisée pour le  SERIAL.
avec une commande du type: GRANT USAGE on lgputils_numuser_seq to public;

Sur le fait de préciser le numuser:

Il est normal que ça ne change rien, puisque la règle en place court-circuite justement ce qui est passé dans numuser ainsi que pour l'autre colonne, seul le mot de passe atterrit dans la table.

Le code cité en exemple ne passe pas sous oracle non plus:

SQL> create table Tutu (isNull_ INTEGER);

Table created.

SQL> insert into Tutu  Values(false);
insert into Tutu  Values(false)
                         *
ERROR at line 1:
ORA-00984: column not allowed here

Autant pour la compatibilité inter-SGBD, le principe d'utiliser des entiers au lieu des booléens se tient tout à fait, autant une fois qu'on a fait ce choix, que vient faire le mot clef false dans une requête? C'est lui qui n'est pas supporté par tous les SGBDs, et  plus généralement le concept de valeur booléenne en SQL (select 1=1 from dual ne fonctionne pas non plus)

Le message d'erreur serait bien utile.

La stratégie par introspection des locks est très délicate. De mémoire les lignes verrouillées ne sont pas dans pg_locks mais sur les pages disque de la table elle-même, l'intérêt étant qu'on peut verrouiller énormément de lignes sans consommer de mémoire ou d'espace disque ailleurs.

Une stratégie plus sûre serait plutôt d'implémenter la condition "ligne pas bloquée" avec une colonne dédiée à ça dans la table, le traitement s'appropriant la ligne avec un UPDATE conditionnel. Eventuellement cette colonne peut être un ID unique de traitement qui fait référence à une table des traitements pour un contrôle fin.