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

  1. Support \if ... \elif ... \else ... \endif in psql scripting.

  2. Add a "void *" passthrough pointer for psqlscan.l's callback functions.