Re: Allowing nonzero return codes from \quit

On Mon, Jan 23, 2017 at 1:26 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

>
> \quit 4
>>>
>>
> As \q does not currently have an argument, this seems an easy and
> reasonnable extension.
>
> However, currently there are 4 existing exit status for psql: 0 (ok), 1
> (fatal error), 2 (connection error), 3 (script error...). +128 status are
> also already used when killing a psql process.
>

I didn't think about it too much, but I don't see why a user couldn't set
one of those error codes.
I did, however, think that any attempt to set an exit_code outside of
[0,127] would itself be an error, resulting in an exit code of 3.

>
> ISTM that quitting with a status should not interfere with these cases at
> least, because a shell could not rely on the exit status to know what went
> wrong? Now having \q 1/2/3 forbidden would also be a strange behavior...
>
> \set exit_code 127
>>> \quit :exit_code
>>>
>>> This isn't a personal need of mine, but I figured it was an idea worth
>>> discussing on its own.
>>>
>>
>> \quit exit_code is better - if we define some special variable, then we
>> have to specify when it should be used and when not. Taking value from
>> command is clean without any another questions.
>>
>
> With minimal luck the second form would probably work out of box if "\quit
> <int>" is implemented because of the way variable substitutions are
> performed.

Yeah, sorry if I wasn't clear on that. I wasn't proposing a special
variable named exit_code. I was just showing the setting of a regular psql
variable.