Certaines versions diffusées de pgadmin ont un bug connu qui positionne une date de validité du mot de passe dans le passé au moment de le changer.
Dans ce cas il est impossible de se connecter avec les méthodes requérant un mot de passe.

Faire

SELECT usename,valuntil FROM pg_user;

pour vérifier et

ALTER USER  nomuser VALID UNTIL 'infinity';

pour corriger si besoin

Le bug est mentionné dans le changelog:
http://www.pgadmin.org/development/changelog.php

Sans connaître ce framework pour OSX, ça ne parait pas anormal qu'il n'y ait pas de recordset en retour d'un INSERT qui ne retourne pas de résultat.

Que se passe-t-il s'il y a une clause RETURNING à cet INSERT pour récupérer un résultat, du style:

insert into images values (lo_import('/pg-imgs/titi.jpg')) returning image

En PostgreSQL moderne (>=8.4) on peut utiliser row_number() plutôt que des séquences ou du code:

select  departement||'-'||row_number() over ( partition by departement) FROM ....

Ca dépend du langage de programmation où varcommune est défini, chaque langage de programmation ayant ses propres méthodes pour injecter une variable dans une requête.

Si le langage est plpgsql, on utilisera plutôt USING ou en second choix la fonction quote_literal.
Si c'était du C on utiliserait la fonction PQescapeStringConn, si PHP pg_escape_string etc...

Un package mais lequel? La doc de PHP en mentionne déjà 4 différents pour MacOS X:
http://www.php.net/manual/fr/install.ma … ckages.php
et il y en a certainement d'autres.

Pour activer le module postgresql dans php, Il faudrait idéalement se référer aux instructions spécifiques du package en question, chaque package ayant ses propres chemins et méthodes.

C'est parce qu'il mangue le / initial au début de /lib...

Mais de toute façon, pour le LD_PRELOAD, avec la version 129 de postgresql-common, en principe ça le fait déjà automatiquement.
Il faut simplement que le package libreadline5 soit installé. C'est apparemment la solution la moins inélégante trouvée en attendant que libedit soit assez évolué pour bien gérer les accents.

Par ailleurs les locales installées comprennent à la fois de l'ISO-LATIN et de l'UTF8 en plus de la locale C qui ne gère pas les accents, ce qui est courant pour un système français mais ça oblige à bien vérifier que le terminal est configuré dans la même locale que psql (faire locale tout seul sans -a pour vérifier la locale courante sous le shell, puis show client_encoding sous psql pour voir si c'est compatible).

En version 8.2 ECPG injecte certainement  le paramètre dans la requête, sans utiliser le PREPARE côté serveur.
Mais depuis 8.3, ECPG utilise le PREPARE côté serveur (voir les notes de version de la doc).

Or le vrai PREPARE est strict sur ce qui peut être paramètre ou pas, en gros seuls les litéraux peuvent être des paramètres. DAYS étant  un mot clef et non un litéral, l'expression "360 DAYS" ne convient pas comme paramètre.

C'est un problème, les autres interfaces comme PDO ou DBD::Pg qui ont opté pour les PREPARE côté serveur ont le même.

La solution est de faire en SQL:

PREPARE stmt_X as SELECT ( now()- $1 * '1 day'::interval )::varchar

et de passer juste le nombre de jours dans le paramètre, sans "DAYS" évidemment.

Et pourtant c'est bien reproductible. Sur un PG9.1 configuré en_US.UTF8:

LC_MESSAGES=fr_FR.UTF8 psql -d test << EOF
show lc_messages;
VACUUM verbose;
EOF

sort

 lc_messages 
-------------
 en_US.UTF-8

suivi de diverses lignes de la forme:

INFO:  vacuuming "pg_toast.pg_toast_11523"
INFO:  index "pg_toast_11523_index" now contains 0 row versions in 1 pages
DÉTAIL : 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.

Avec tout en anglais, sauf DÉTAIL avec son accent.

Je pense que c'est parce que DETAIL ne fait pas vraiment corps avec la sortie de VACUUM VERBOSE, c'est un ajout du client psql sur le niveau de cricité du message (notice,info,avertissement, etc...)

PS: mais ce sont des logs côté client, donc ce n'est pas supposé être analysé avec pgfouine?

Le sujet est couvert par la doc:
REINDEX: http://docs.postgresql.fr/9.1/sql-reindex.html
CLUSTER: http://docs.postgresql.fr/9.1/sql-cluster.html

Il ya 2 options: soit arranger les valeurs directement dans la requête sous forme de tableau, exemple

select multi_upsert(array[7,3,-3,2], array[1,2,3,4]);

soit utiliser le passage en paramètre de tableaux C# avec Npgsql, puisque c'est visiblement géré d'après la doc:
http://npgsql.projects.postgresql.org/d … anual.html
(chapitre "Working with arrays")

A la première exception, la transaction va être annulée et l'erreur remontée à l'appelant, c'est le comportement par défaut.

Le MERGE en masse est faisable  par un UPDATE multiple + INSERT multiple pour toute une collection de valeurs, dans une fonction procédurale, les paramètres des requêtes étant passés  dans des tableaux.

Voici un exemple pour des données de type clef/valeur dans une table a(id int primary key, val int).
Les valeurs à insérer ou remplacer sont passées dans arrval et les clefs dans arrkey (ces tableaux doivent impérativement être de taille identique pour que les unnest() des sous-requêtes sortent les valeurs alignées côte à côte).

CREATE FUNCTION multi_upsert(arrval int[], arrkey int[]) returns void as $$
begin
  UPDATE a SET val=s.v FROM
    (SELECT unnest(arrval) as k,unnest(arrkey) as v) s
    WHERE id=s.k;

  INSERT INTO a(id,val) select k,v
    from (SELECT unnest(arrval) as k,unnest(arrkey) as v) s
      WHERE not exists(select 1 from a where id=s.k);

end
$$ language plpgsql;

Cette fonction ne gère pas le problème les mises à jour concurrentes, mais le code C# montré ne le faisant pas non plus, ce n'est apparemment pas nécessaire. Sinon on pourrait ajouter un réessai sur EXCEPTION comme dans la doc de postgres ou un verrouillage explicite  avant l'INSERT.

Côté performance, le gain à espérer est important par rapport à la séquence INSERT-UPDATE dans le code client,  du fait non seulement du groupement en deux requêtes, mais surtout de la réduction au minimum des aller-retours client-serveur sur le réseau, surtout si c'est un vrai réseau  (pas localhost).

Pour finir, j'ai intégré les modifs pour VS2010 au point où ça compile sans warning ni erreur (et où un test de requête basique fonctionne), j'ai fait le ménage de printemps dans le code, et j'ai mis le résultat sur github:
https://github.com/manitou-mail/pgstream