Обсуждение: 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) Whereaspsql --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