Re: psql ignores failure to open -o target file - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: psql ignores failure to open -o target file
Date
Msg-id CAKFQuwa0dFkanVyMOsi8mHT+pNrRwv+qw04mALa6ACqxXq8Nww@mail.gmail.com
Whole thread Raw
In response to Re: psql ignores failure to open -o target file  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: psql ignores failure to open -o target file  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I just noticed that parse_psql_options() ignores the result of setQFout(),
> meaning that if the argument of a -o command line option is bogus, we'll
> ignore the switch entirely after printing an error report.  For example
>
> $ psql -o /dev/foo -c 'select 1'
> /dev/foo: Permission denied
>  ?column?
> ----------
>         1
> (1 row)
>
> $
>
> This seems surprising to me: any other program in the world would do
> exit(1) after discovering that it couldn't write where it had been
> told to.  Should we change this?

I assume this is a rhetorical question.


How about this one: do we change this behavior in the back branches?

​Given other instances of in script errors not causing psql to exit (hence ON_ERROR_STOP) this doesn't seem as surprising as it is being made out to be.

David J.


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: psql: add \pset true/false
Next
From: Tom Lane
Date:
Subject: Re: psql ignores failure to open -o target file