Comment obtenir des avis sur le flux de sortie?

20

J'ai des messages de débogage dans les fonctions. Ces messages sont élevés comme

RAISE NOTICE 'Value of id : %', id;

J'ai défini mon fichier journal avec \o messages.txt

Ensuite, je fais ce que je dois faire avec \i process.sql

Et lorsque l'exécution est terminée, \o.

Le problème est que je n'ai pas les messages soulevés par les notifications dans messages.txt. Les messages sont affichés à l'écran mais je veux qu'ils soient écrits dans messages.txt

Comment pourrais-je faire ça?

J'ai essayé d'utiliser RAISE LOG...et les messages sont écrits dans le fichier journal ... Ce n'est pas ce que je veux.

J'ai du travail avec

plsql -f /path/to/process.sql > messages.txt 2>&1

mais je voudrais savoir comment je pourrais utiliser \ i et \ o sur le client plsql ayant les messages dans le fichier spécifié dans \ o

Mon client, sur cygwin est psql (PostgreSQL) 8.2.11 et la version du serveur est 9.0.7

Luc M
la source
1
Bien que ce ne soit pas la cause de votre problème, l'utilisation de psql 8.2 contre Pg 9.0 peut vous causer toutes sortes de problèmes en raison de toutes les modifications du schéma du catalogue système et des nouvelles fonctionnalités du serveur. Si vous rencontrez des problèmes étranges ou inattendus, essayez avec psql 9.x.
Craig Ringer
@CraigRinger Le problème est que le psql client pour cygwin n'est pas disponible. Au moins la dernière fois que j'ai essayé de mettre à jour le client sur cygwin. Je ne peux pas utiliser la fonctionnalité \ d mais tout le reste semble correct.
Luc M
@CraigRinger Ne savait pas que le client n'était plus pris en charge. Merci.
Luc M
J'ai juste revérifié cela; Je pensais que cygwin n'était pas pris en charge et je n'avais entendu parler de personne qui l'utilisait depuis des lustres, mais il semble que les gens continuent de construire PostgreSQL 9.2 beta sur Cygwin dans la buildfarm ; voir brolga . Ça devrait marcher. Vous devrez probablement compiler à partir des sources si vous voulez le Pg actuel, ce ne seront que les paquets binaires Cygwin qui ne sont pas maintenus. Je supprimerai ce commentaire pour éviter toute confusion future.
Craig Ringer
La question demeure cependant: pourquoi utiliser Cygwin pour psql? libpqJe pourrais comprendre si vous avez un logiciel non portable qui doit fonctionner dans Cygwin, mais quand psqlest-il disponible en natif pour Windows, quel est l'intérêt de lancer une ancienne version sur Cygwin?
Craig Ringer

Réponses:

8

Je crains que vous n'aimiez pas cette réponse, mais actuellement cela semble impossible. De la documentation psql :

Enregistre les résultats des requêtes futures dans le fichier nom de fichier ou dirige les résultats futurs dans un shell Unix distinct pour exécuter la commande. Si aucun argument n'est spécifié, la sortie de la requête sera réinitialisée à la sortie standard.

Les «résultats de la requête» incluent toutes les tables, les réponses aux commandes et les avis obtenus à partir du serveur de base de données, ainsi que la sortie de diverses commandes antislash qui interrogent la base de données (telles que \ d), mais pas les messages d'erreur.

Et comme vous l'avez remarqué, il n'y a aucun moyen de rediriger les messages d'erreur lors d'une utilisation psqlinteractive.

(J'ai joué avec toutes sortes de redirection de \ o en vain. Il semble que le canal de sortie de la requête soit différent de celui qui reçoit les messages d'erreur - et même les erreurs du serveur et remontées dans vos procédures vont de différentes manières .

test=# SHOW client_min_messages;
 client_min_messages
---------------------
 notice

-- added the above to show it's not a config problem

CREATE FUNCTION raise_test() RETURNS integer AS
$body$
BEGIN
    RAISE NOTICE 'notice';
    RETURN 1;
END;
$body$
LANGUAGE plpgsql;

test=# \o | cat > out.sql
test=# SELECT raise_test(); -- you could put this in a file and call \i your_file, it's just the same
NOTICE:  notice

test=# \o | cat > out.sql 2>&1
test=# SELECT raise_test();
NOTICE:  notice

out.sql contient

 raise_test
------------
          1
(1 row)

dans les deux cas. C'est pourquoi je ne sais pas quel descripteur de canal / fichier est utilisé pour sortir les messages générés par une procédure.))

(Il existe un fil sur les pirates PostgreSQL qui peut apporter un éclairage sur ce problème: http://postgresql.1045698.n5.nabble.com/psql-output-locations-td5068313.html )

Ce que l'on pourrait faire, c'est commencer psqlcomme

psql test >/tmp/psql.out 2>&1

et cela redirigera toutes les sorties vers le fichier spécifié. Le seul problème avec cela, vous n'avez même pas d'invite et vous perdez les capacités d'édition en ligne de commande.

dezso
la source
1
Non, je n'aime pas ta réponse. :-)
Luc M
le descripteur de canal / fichier est utilisé pour sortir les messages issus d'une procédure : c'est l'erreur standard. \o | cat > out.sql 2>&1redirige l'erreur standard de catmais pas celle de psql, il est donc inutile pour les avis.
Daniel Vérité
@dezso, comment pgAdmin ou tout autre outil graphique affiche les NOTICEinformations?
Spike
@Spike, ils ne sont pas construits sur psql, donc probablement sans aucun problème.
dezso
@dezso, ouais je comprends. J'ai eu un problème comme, je me suis mis client_min_messageà l' debugintérieur de ma session et j'exécute quelques sqls dynamiques avec ( DO- sans créer de fonction), cela fait remarquer dans pgAdmin pas avec psql. J'ai imprimé la client_min_messagevaleur avant d'exécuter l' DOinstruction. Il s'affiche debug, mais le message ne s'imprime pas dans la console.
Spike
2

Nous pouvons exécuter la commande shell directement à partir de psql en utilisant la \!commande meta.

localhost: 5432 utilisateur @ db = # \! psql -U user -h localhost your_database -e 'select your_function_name ()'> debug.txt 2> & 1

ouvrir debug.txtavec \e.

localhost: 5432 utilisateur @ db = # \ e debug.txt

soulever le message s'affichera dans votre éditeur par défaut. un peu délicat, toujours très pratique pour les amoureux de commandLine.

Brain90
la source
0

Pas une solution à la question d'origine, mais un ajout à la solution de contournement d'OP (qui n'a pas fonctionné pour moi)


Avec ce qui suit comme raiseTest.sql

BEGIN;

CREATE FUNCTION count_to_hundred() RETURNS VOID AS
$_$
BEGIN
    FOR i IN 1..100 
    LOOP
        RAISE NOTICE '%', i;
    END LOOP;

    RETURN;
END;
$_$
LANGUAGE plpgsql;


SELECT count_to_hundred();

ROLLBACK;



Je ne suis pas sûr, pourquoi l'écriture de la sortie dans un fichier comme indiqué dans l'OP ne fonctionne pas, mais la canalisation dans le tee a en fait fonctionné:

psql -f raiseTest.sql 2>&1 | tee messages.txt


Tee écrit le stdin dans un ou plusieurs fichiers et le remet dans le stdout. Vous aurez donc toutes les instructions RAISE dans votre console et dans le ou les fichiers que vous avez fournis. (cf. page de manuel de tee )


Configuration:

  • Postgres 8.4
  • Cygwin 2.0.2
  • tee 8.23
Père pile
la source
La question consistait à faire passer les messages NOTICEpendant que vous participez à une session interactive et à les utiliser\o
Luc M
Oh, tu es là. J'ai totalement raté cette partie, car la solution de contournement dans le PO n'a pas fonctionné pour moi et je me suis concentré uniquement sur cela.
Father Stack