Re: [HACKERS] psql ignores failure to open -o target file

2015-12-02 Thread David G. Johnston
On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas  wrote:

> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane  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.


Re: [HACKERS] psql ignores failure to open -o target file

2015-12-02 Thread Tom Lane
"David G. Johnston"  writes:
> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas  wrote:
>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane  wrote:
>>> 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?

I don't think we should change this in stable branches.  I would vote
for fixing it in 9.5, though, mainly because the fix is going to interact
with the extended-mode-wrap fixes I'm also working on.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql ignores failure to open -o target file

2015-12-02 Thread Tom Lane
I 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.

There's more silliness in the same area.  \o with an invalid target spec
is treated like \o with no argument, ie, revert the target to stdout:

regression=# \o somefile
regression=# select 1;  -- output goes to somefile, as expected
regression=# \o /dev/bogus
/dev/bogus: Permission denied
regression=# select 1;
 ?column? 
--
1
(1 row)

Surely that should have no effect beyond printing the error message.

Also, I notice that we try to set SIGPIPE handling to SIG_IGN whenever
the \o target is a pipe, which is good; but places that transiently
change SIGPIPE handling will unconditionally reset it back to SIG_DFL.
One such place is ClosePager().  That bug seems only latent because we
only invoke a pager when queryFout == stdout, so we would never get
there while the target is a pipe.  But another such place is do_copy(),
and we definitely can call that while \o is set to a pipe.

In short, a bit of refactoring is needed around setQFout...

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql ignores failure to open -o target file

2015-12-02 Thread Robert Haas
On Wed, Dec 2, 2015 at 1:24 PM, Tom Lane  wrote:
> "David G. Johnston"  writes:
>> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas  wrote:
>>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane  wrote:
 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?
>
> I don't think we should change this in stable branches.  I would vote
> for fixing it in 9.5, though, mainly because the fix is going to interact
> with the extended-mode-wrap fixes I'm also working on.

Oh.  I would assume this was an obvious back-patch back to the stone
age.  It seems like flagrant bug.  Let's revive 7.4 just to fix this.
:-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] psql ignores failure to open -o target file

2015-12-02 Thread Robert Haas
On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane  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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers