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
"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. Shou
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 afte
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
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
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?
--
