Re: psql ignores failure to open -o target file

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql ignores failure to open -o target file
Date: 2015-12-02 18:18:00
Message-ID: CAKFQuwa0dFkanVyMOsi8mHT+pNrRwv+qw04mALa6ACqxXq8Nww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-12-02 18:24:49 Re: psql ignores failure to open -o target file
Previous Message Jim Nasby 2015-12-02 18:10:18 Re: psql: add \pset true/false