Re: Allowing nonzero return codes from \quit

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allowing nonzero return codes from \quit
Date: 2017-01-23 18:26:42
Message-ID: alpine.DEB.2.20.1701231918400.31421@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> \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.

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.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2017-01-23 18:31:54 Re: Undefined psql variables
Previous Message Kevin Grittner 2017-01-23 18:26:32 Re: [PATCH] Add GUCs for predicate lock promotion thresholds