Re: [HACKERS] Allowing nonzero return codes from \quit
От
Fabien COELHO
Тема
Re: [HACKERS] Allowing nonzero return codes from \quit
Дата
Msg-id
alpine.DEB.2.20.1701232140500.31421@lancre
Ответ на
Re: [HACKERS] Allowing nonzero return codes from \quit (Corey Huinker)
Список
Дерево обсуждения
[HACKERS] Allowing nonzero return codes from \quit Corey Huinker <corey.huinker@gmail.com>
Re: [HACKERS] Allowing nonzero return codes from \quit Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] Allowing nonzero return codes from \quit Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] Allowing nonzero return codes from \quit Corey Huinker <corey.huinker@gmail.com>
Re: [HACKERS] Allowing nonzero return codes from \quit Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] Allowing nonzero return codes from \quit Tom Lane <tgl@sss.pgh.pa.us>
>> 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. Hmmm. Maybe it should let the user shoots its own foot if desired, just a reminder in the doc of a possible interference with existing codes would be enough? -- Fabien.
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: