Re: [HACKERS] Allowing nonzero return codes from \quit

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: [HACKERS] Allowing nonzero return codes from \quit
Дата
Msg-id CADkLM=fjZK8D28kCT0TA5y3drTrfFsyeDL08wL3jovvs8gLUpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Allowing nonzero return codes from \quit  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] Allowing nonzero return codes from \quit  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On Mon, Jan 23, 2017 at 1:26 PM, Fabien COELHO <coelho@cri.ensmp.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Add function to import operatingsystem collations