Re: psql return codes - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: psql return codes
Date
Msg-id 20061206185103.GN44124@nasby.net
Whole thread Raw
In response to Re: psql return codes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: psql return codes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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)


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: old synchronized scan patch
Next
From: "Simon Riggs"
Date:
Subject: Re: old synchronized scan patch