Allowing nonzero return codes from \quit
Another suggestion to come out of the \quit_if discussion was that someone
might want to send a return code other than 0 back. Something like this:
\quit 4
or even:
\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.
2017-01-23 19:09 GMT+01:00 Corey Huinker <corey.huinker@gmail.com>:
Another suggestion to come out of the \quit_if discussion was that someone
might want to send a return code other than 0 back. Something like this:\quit 4
or even:
\set exit_code 127
\quit :exit_codeThis 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.
Regards
Pavel
\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_codeThis 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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.
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
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?
Yeah, I see no reason why scripts shouldn't be allowed to return one of
those codes if they like. We do need to constrain it to [0,127] for
sanity though, or possibly [0,125] --- doesn't POSIX mandate special
meaning for 126 and 127?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers