psql return codes
Currently, if we issue this command
psql --set ON_ERROR_STOP= -f f.sql
where f.sql has "select * from foo;"
then psql will return
0 if foo exists
3 if foo does not exist (or other SQL error)
Whereas
psql --set ON_ERROR_STOP= -c "select * from foo;"
returns
0 if foo exists
1 if foo does not exist (or other SQL error)
Is this a minor oversight, or some aspect of design?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote:
Currently, if we issue this command
psql --set ON_ERROR_STOP= -f f.sql
where f.sql has "select * from foo;"
then psql will return
0 if foo exists
3 if foo does not exist (or other SQL error)Whereas
psql --set ON_ERROR_STOP= -c "select * from foo;"
returns
0 if foo exists
1 if foo does not exist (or other SQL error)Is this a minor oversight, or some aspect of design?
Well, our psql manual page has:
EXIT STATUS
psql returns 0 to the shell if it finished normally, 1 if
a fatal error of its own (out of memory, file not found)
occurs, 2 if the connection to the server went bad and the
session was not interactive, and 3 if an error occurred in
a script and the variable ON_ERROR_STOP was set.
Were you asking if this behavior is documented, or if it is desirable?
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Wed, Dec 06, 2006 at 09:53:17AM -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Currently, if we issue this command
psql --set ON_ERROR_STOP= -f f.sql
where f.sql has "select * from foo;"
then psql will return
0 if foo exists
3 if foo does not exist (or other SQL error)Whereas
psql --set ON_ERROR_STOP= -c "select * from foo;"
returns
0 if foo exists
1 if foo does not exist (or other SQL error)Is this a minor oversight, or some aspect of design?
Well, our psql manual page has:
EXIT STATUS
psql returns 0 to the shell if it finished normally, 1 if
a fatal error of its own (out of memory, file not found)
occurs, 2 if the connection to the server went bad and the
session was not interactive, and 3 if an error occurred in
a script and the variable ON_ERROR_STOP was set.Were you asking if this behavior is documented, or if it is desirable?
Maybe I'm just dense this AM, but I'm not seeing how that explains what
Simon is seeing? Why should it matter if the "SELECT * FROM foo" came to
psql via -f or -c?
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote:
Well, our psql manual page has:
EXIT STATUS
psql returns 0 to the shell if it finished normally, 1 if
a fatal error of its own (out of memory, file not found)
occurs, 2 if the connection to the server went bad and the
session was not interactive, and 3 if an error occurred in
a script and the variable ON_ERROR_STOP was set.Were you asking if this behavior is documented, or if it is desirable?
Maybe I'm just dense this AM, but I'm not seeing how that explains what
Simon is seeing? Why should it matter if the "SELECT * FROM foo" came to
psql via -f or -c?
Well, it explains exactly what Simon was seeing. I agree it is strange,
but I was asking if Simon knew it was documented. I assume the "3" is
used to report a different error from 'file not found' or something.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Jim C. Nasby wrote:
Why should it matter if the "SELECT * FROM foo" came to
psql via -f or -c?
Well, it explains exactly what Simon was seeing. I agree it is strange,
but I was asking if Simon knew it was documented. I assume the "3" is
used to report a different error from 'file not found' or something.
Well, the real point here is that ON_ERROR_STOP doesn't apply to
interactive input, and -c is evidently being considered to be
interactive. You could argue that either way I suppose, but seeing
that -c can only issue a single command, implementing ON_ERROR_STOP
for it seems like largely a waste of effort.
regards, tom lane
On Wed, 2006-12-06 at 14:25 -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Jim C. Nasby wrote:
Why should it matter if the "SELECT * FROM foo" came to
psql via -f or -c?Well, it explains exactly what Simon was seeing. I agree it is strange,
but I was asking if Simon knew it was documented.
Yes, but it doesn't say what a "script" is and doesn't explain either.
I assume the "3" is
used to report a different error from 'file not found' or something.
Well, the real point here is that ON_ERROR_STOP doesn't apply to
interactive input, and -c is evidently being considered to be
interactive. You could argue that either way I suppose
I'm all ears...
, but seeing
that -c can only issue a single command, implementing ON_ERROR_STOP
for it seems like largely a waste of effort.
The main point is that rc=1 doesn't always mean the same thing, which
makes it harder to write scripts that handle errors correctly.
It may be a small thing, but that doesn't make it right.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
"Simon Riggs" <simon@2ndquadrant.com> writes:
On Wed, 2006-12-06 at 14:25 -0500, Tom Lane wrote:
, but seeing
that -c can only issue a single command, implementing ON_ERROR_STOP
for it seems like largely a waste of effort.
The main point is that rc=1 doesn't always mean the same thing, which
makes it harder to write scripts that handle errors correctly.
You seem to be assuming that -c input should be treated exactly like
script input, which it is not and never has been --- eg, it's not
pre-split at semicolons before submission to the backend. In a green
field doubtless we'd make them more alike, but at this point we really
can't close the gap without risking subtle breakage of people's scripts.
So I don't feel a strong need to make them more consistent on this point
either. The return codes *are* consistent as long as you compare apples
to apples. If you expect -c to be exactly interchangeable with script
input then you're going to get burnt on a lot more than this.
regards, tom lane