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  (Corey Huinker <corey.huinker@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: [HACKERS] Undefined psql variables