Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have debugging messages in functions. Those message are raised like

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

I set my log file with \o messages.txt

Then I do what I need to do with \i process.sql

And when the execution is terminated, \o.

The problem is that I don't have the messages raised by notices into messages.txt. The messages are displayed on the screen but I want them to be written in messages.txt

How could I do that ?

I tried to use RAISE LOG... and messages are written in log file... It's not what I want.

I have a work around with

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

but I would like to know how I could use \i and \o on plsql client having the messages into the file specified in \o

My client, on cygwin is psql (PostgreSQL) 8.2.11 and the server version is 9.0.7

share|improve this question
    
While not the cause of your problem, using psql 8.2 against Pg 9.0 may cause you all kinds of grief because of all the system catalog schema changes and new server features. If you encounter weird or unexpected issues, try with psql 9.x. –  Craig Ringer Sep 4 '12 at 22:09
    
@CraigRinger The problem is that the client psql for cygwin is not available. At least the last time I tried to upgrade the client on cygwin. I can't use the \d functionnality but everything else seem ok. –  Luc M Sep 4 '12 at 23:51
    
@CraigRinger Didn't know that the client wasn't supported anymore. Thanks. –  Luc M Sep 5 '12 at 0:10
    
I just double checked that; I thought cygwin was unsupported and I hadn't heard of anyone using it for ages, but it looks like people are still building PostgreSQL 9.2 beta on Cygwin in the buildfarm; see brolga. It should work. You'll probably just have to compile from source if you want the current Pg, it'll just be the binary Cygwin packages that're unmaintained. I'll delete that comment to avoid any future confusion. –  Craig Ringer Sep 5 '12 at 0:18
    
The question remains though: Why use Cygwin for psql? libpq I could understand if you have non-portable software that has to run in Cygwin, but when psql is available natively for Windows what's the appeal of running an ancient version on Cygwin? –  Craig Ringer Sep 5 '12 at 0:24
show 2 more comments

1 Answer

up vote 3 down vote accepted

I'm afraid that you won't like this answer, but currently it seems impossible. From the psql documentation:

Saves future query results to the file filename or pipes future results into a separate Unix shell to execute command. If no arguments are specified, the query output will be reset to the standard output.

"Query results" includes all tables, command responses, and notices obtained from the database server, as well as output of various backslash commands that query the database (such as \d), but not error messages.

And as you noticed, there is no way redirecting error messages when using psql interactively.

(I've been playing around with all kinds of redirection from \o to no avail. It looks like that the query output channel is different from the one getting error messages - and even errors from the server and raised in your procedures go different ways.

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 contains

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

in both cases. This is why I am clueless about what channel/file descriptor is used for outputting the messages raised from a procedure.) )

(There is a thread on PostgreSQL-hackers that may shed some light on this issue: http://postgresql.1045698.n5.nabble.com/psql-output-locations-td5068313.html )

share|improve this answer
    
No, I don't like your answer. :-) –  Luc M Sep 4 '12 at 13:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.