Re: [GENERAL] Suggested "minor" change to psql - Mailing list pgsql-general
From | Peter Eisentraut |
---|---|
Subject | Re: [GENERAL] Suggested "minor" change to psql |
Date | |
Msg-id | Pine.LNX.4.20.9912090130100.389-100000@localhost.localdomain Whole thread Raw |
In response to | Suggested "minor" change to psql (Mark Dalphin <mdalphin@amgen.com>) |
List | pgsql-general |
On 1999-12-08, Mark Dalphin mentioned: > Sometimes, however, rather than using the "\i" command, I would like to simply > load my schema directly into psql and capture the output on STDOUT (ie "psql < > mySchema.sql >& myOutput"). The problem that arises is that the errors and > notices all come out on STDERR. I am not sure this is the right choice. Because > of the lack of synchronization between STDOUT and STDERR, it becomes impossible > to associate an SQL statement with either a CREATE or an ERROR message. The > option, "-e", is supposed to echo the query, but it doesn't help. You might be glad to hear that I've been addressing these issues. The way it currently looks is that everything that is related to backend traffic (query results, INSERT xxx, notices, errors) will all go to the same stream (the \o one) in the order they arrive. I think this is what everyone wanted. If you are running interactively, it doesn't make a difference anyway, but in a automated script you'll rarely have the need to have the errors without the commands that caused them. The only thing that will keep going to stderr are fatal notices from psql itself. The only thing that always goes to stdout is psql internal messages ("Turned on expanded mode."). One additional feature that's coming up, which you might like, is the possibility to stop such a psql script after the first error it encounters. > While I can see wanting to separate STDERR and STDOUT when one uses psql to run > an SQL query against a DB from within a shell script, it makes it much more > difficult when developing, and if I were to run several SQL queries into psql, > exactly the same association problem would occur. You can check the return code and decide what to do with the output that way. > Perhaps a combination of the function "isatty()" plus the -e flag would work? So > that if STDOUT "isatty()" then echo errors to STDOUT, otherwise send them to > STDERR. And if the -e flag is set, echo the queries to STDERR, so the > correlation between ERROR, CREATE, etc and SQL could be made. There are already about 4 or 5 different output sources and 2 or 3 states controlling them; I'm hesitant to adding more confusion, especially subtle things. Also, the meaning of the -e flag has been adjusted. In interactive mode it doesn't do anything, in script mode it prints every line as it reads it. If you don't give it, you don't see the code of your script. That is more like a regular shell. > PS I only recently learned of the setting of the PAGER environment variable to > make it so I needn't scroll back up 400 lines to find my errors; perhaps this > could be made more prominent in the documentation as it would be a big help. That part has been changed, because the purpose of the PAGER environment variable in general is not to toggle the use of the pager in psql. There is now an internal switch. > Then again, perhaps I should completely re-read the docs to see if this is > mentioned; I haven't done that for several releases now. Well, I rewrote the complete manual, so you're in for a great work of literature. :) When will you be able to reach this promised land? You could start by flaming the hackers list about a 6.6 release in Feb/Mar ... ;) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
pgsql-general by date: