Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Corey Huinker" <corey.huinker@gmail.com>
Cc: "Fabien COELHO" <coelho@cri.ensmp.fr>,"Erik Rijkers" <er@xs4all.nl>,"Tom
Lane" <tgl@sss.pgh.pa.us>,"Jim Nasby"
<Jim.Nasby@bluetreble.com>,"PostgreSQL"
<pgsql-hackers@postgresql.org>,pgsql-hackers-owner@postgresql.org
Date: 2017-02-04T11:37:24Z
Lists: pgsql-hackers
Corey Huinker wrote: [about Ctrl-C] > That does seem to be the consensus desired behavior. I'm just not sure > where to handle that. The var "cancel_pressed" shows up in a lot of places. > Advice? Probably you don't need to care about cancel_pressed, and the /if stack could be unwound at the point the SIGINT handler longjumps to, in mainloop.c: /* got here with longjmp */ /* reset parsing state */ psql_scan_finish(scan_state); psql_scan_reset(scan_state); resetPQExpBuffer(query_buf); resetPQExpBuffer(history_buf); count_eof = 0; slashCmdStatus = PSQL_CMD_UNKNOWN; prompt_status = PROMPT_READY; pset.stmt_lineno = 1; cancel_pressed = false; The check I was suggesting on whether Ctrl+C has been pressed on an empty line seems harder to implement, because get_interactive() just calls readline() or fgets(), which block to return when a whole line is ready. AFAICS psql can't know what was the edit-in-progress when these functions are interrupted by a signal instead of returning normally. But I don't think this check is essential, it could be left to another patch. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
Commits
-
Support \if ... \elif ... \else ... \endif in psql scripting.
- e984ef5861df 10.0 landed
-
Add a "void *" passthrough pointer for psqlscan.l's callback functions.
- 895e36bb3f36 10.0 landed