Re: [HACKERS] Allowing nonzero return codes from \quit
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] Allowing nonzero return codes from \quit |
Дата | |
Msg-id | alpine.DEB.2.20.1701231918400.31421@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] Allowing nonzero return codes from \quit (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] Allowing nonzero return codes from \quit
|
Список | 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.
В списке pgsql-hackers по дате отправления: