Re: [GENERAL] Suggested "minor" change to psql

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Mark Dalphin <mdalphin(at)amgen(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Suggested "minor" change to psql
Date: 1999-12-10 01:28:41
Message-ID: Pine.LNX.4.20.9912090130100.389-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Otavio Exel 1999-12-10 01:53:37 Re: [GENERAL] Suggested "minor" change to psql
Previous Message Peter Bojanic 1999-12-09 20:26:09 Problems with pg_dump

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-12-10 01:42:38 Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY andshift/reduce)
Previous Message Peter Eisentraut 1999-12-10 01:28:29 Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY andshift/reduce)