Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-14 Thread Robert Haas
On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote: > What would be the mnemonic for "," an "@"? Oh, I just picked it because control-@ is the nul character, and your commands would be nullified. I realize that's pretty weak, but we're talking about finding a punctuation

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-14 Thread Fabien COELHO
For two states: * for being executed (beware, it is ***important***) It does lend importance, but that's also the line continuation marker for "comment". Would that be a problem? Argh. Indeed, even if people seldom type C comments in psql interactive mode... Remaining ASCII characters

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-14 Thread Corey Huinker
> > @in't gonna execute it? >> > > Hmmm... This is too much of an Americanism, IMHO. The @ looks like a handwritten 'a'. @in't gonna => ain't gonna => will not. It's a bad joke, made as a way of saying that I also could not think of a good mnemonic for '@' or ','. > I'm here all week, try the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-13 Thread Fabien COELHO
Hello Corey, If I can find some simple mnemonic for "," vs "@" for being executed vs ignored, I could live with that, but nothing obvious comes to my mind. @in't gonna execute it? Hmmm... This is too much of an Americanism, IMHO. I'm here all week, try the veal. Sorry, syntax error,

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-13 Thread Corey Huinker
On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote: > > Hello Robert, > > [...] I think we should try to make this REALLY simple. We don't really >> want to have everybody have to change their PROMPT1 and PROMPT2 strings for >> this one feature. >> > > Ok. I think that we

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-13 Thread Corey Huinker
On Mon, Feb 13, 2017 at 11:29 AM, Robert Haas wrote: > possible states here. Just when you've figured out what tfzffft I agree with what you've said, but wanted to point out that any condition that follows a 'z' would itself be 'z'. Not that tfz is much better.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-13 Thread Fabien COELHO
Hello Robert, [...] I think we should try to make this REALLY simple. We don't really want to have everybody have to change their PROMPT1 and PROMPT2 strings for this one feature. Ok. I think that we agree that the stack was too much details. How about just introducing a new value for

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-13 Thread Robert Haas
On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO wrote: >> Ok, so that's not just PROMPT_READY, that's every prompt...which might be >> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd >> level always being '.'? > > Yep. The idea is to keep it short, but

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-11 Thread Corey Huinker
On Sat, Feb 11, 2017 at 3:48 PM, Fabien COELHO wrote: > > Just realized that '?' means "unknown transactional status" in %x. That >> might cause confusion if a person had a prompt of %x%R. Is that enough >> reason to pick a different cue? >> > > Argh. > > "\?\.?[tfz]" seems

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-11 Thread Fabien COELHO
Just realized that '?' means "unknown transactional status" in %x. That might cause confusion if a person had a prompt of %x%R. Is that enough reason to pick a different cue? Argh. "\?\.?[tfz]" seems distinctive enough. Note that %R uses "'=-*^!$( and %x uses *!?, which means that they

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-11 Thread Corey Huinker
On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO wrote: > > Ok, so that's not just PROMPT_READY, that's every prompt...which might be >> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd >> level always being '.'? >> > > Yep. The idea is to keep it

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-10 Thread Fabien COELHO
Ok, so that's not just PROMPT_READY, that's every prompt...which might be ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd level always being '.'? Yep. The idea is to keep it short, but to still have something to say "there are more levels" in the stack, hence the one

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-10 Thread Corey Huinker
> > calvin=> \if true > calvin?t=> SELECT 1 + > calvin?t-> 2; > 3 > calvin?t=> \if true > calvin?t=> \echo hello > hello > calvin?t=> \endif > calvin?t=> \else > calvin?z=> \echo ignored > calvin?t=> \endif > calvin=> > Ok, so that's not just PROMPT_READY, that's

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-10 Thread Fabien COELHO
Hello, I'm looking forward to the doc update. My 0.02€ about prompting: Given that there is no more barking, then having some prompt indication that the code is inside a conditional branch becomes more important, so ISTM that there should be some plan to add it. Yeah, prompting just got

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-10 Thread Corey Huinker
> > Shouldn't there be some documentation changes to reflect the behavior on > errors? A precise paragraph about that would be welcome, IMHO. > Oddly enough, the documentation I wrote hadn't addressed invalid booleans, only the error messages did that. The new behavior certainly warrants a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Fabien COELHO
Hello Corey, Changes in this patch: - invalid boolean expression on \if or \elif is treated as if the script had a bad \command, so it either stops the script (ON_ERROR_STOP, script mode), or just gives the ParseVariableBool error and continues. - All interactive "barks" removed except

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Corey Huinker
On Thu, Feb 9, 2017 at 4:43 PM, Erik Rijkers wrote: > On 2017-02-09 22:15, Tom Lane wrote: > >> Corey Huinker writes: >> > > The feature now ( at patch v10) lets you break off with Ctrl-C anywhere. > I like it now much more. > > The main thing I still

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Erik Rijkers
On 2017-02-09 22:15, Tom Lane wrote: Corey Huinker writes: The feature now ( at patch v10) lets you break off with Ctrl-C anywhere. I like it now much more. The main thing I still dislike somewhat about the patch is the verbose output. To be honest I would

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Robert Haas
On Thu, Feb 9, 2017 at 4:15 PM, Tom Lane wrote: > Basically, I think you need to start removing complexity (in the sense of > special cases), not adding more. I think Robert was saying the same > thing, though possibly I shouldn't put words in his mouth. Yeah, I was

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Tom Lane
Corey Huinker writes: > On Thu, Feb 9, 2017 at 3:13 PM, Tom Lane wrote: >> IMO, an erroneous backslash command should have no effect, period. > One way around this is to make the small change: commands with invalid > expressions are ignored in

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Corey Huinker
On Thu, Feb 9, 2017 at 3:13 PM, Tom Lane wrote: > Robert Haas writes: > > I (still) think this is a bad design. Even if you've got all the > > messages just right as things stand today, some new feature that comes > > along in the future can change

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Tom Lane
Robert Haas writes: > I (still) think this is a bad design. Even if you've got all the > messages just right as things stand today, some new feature that comes > along in the future can change things so that they're not right any > more, and nobody's going to relish

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-09 Thread Robert Haas
On Mon, Feb 6, 2017 at 5:49 PM, Corey Huinker wrote: > I suppressed the endif-balance checking in cases where we're in an > already-failed situation. > In cases where there was a boolean parsing failure, and ON_ERROR_STOP is on, > the error message no longer speak of a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-07 Thread Fabien COELHO
This was my previous understanding of ON_ERROR_STOP. Somewhere in the course of developing this patch I lost that. Glad to have it back. The only changes I made were to invalid booleans on if/elif, and the final branch balancing check won't set status to EXIT_USER unless it's non-interactive

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-07 Thread Corey Huinker
> > > It seems that ON_ERROR_STOP is mostly ignored by design when in > interactive mode, probably because it is nicer not to disconnect the user > who is actually typing things on a terminal. > > """ > ON_ERROR_STOP > > By default, command processing continues after an error. When this >

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Fabien COELHO
Hello Corey, In cases where there was a boolean parsing failure, and ON_ERROR_STOP is on, the error message no longer speak of a future which the session does not have. I could left the ParseVariableBool() message as the only one, but wasn't sure that that was enough of an error message on its

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Corey Huinker
On Mon, Feb 6, 2017 at 3:43 PM, Corey Huinker wrote: > I did some more tests. I found a subtlety that I missed before: when >> running under ON_ERROR_STOP, messages are not fully consistent: >> >> sh> cat test.sql >> \set ON_ERROR_STOP on >> \if error >>\echo NO

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Corey Huinker
> > I did some more tests. I found a subtlety that I missed before: when > running under ON_ERROR_STOP, messages are not fully consistent: > > sh> cat test.sql > \set ON_ERROR_STOP on > \if error >\echo NO > \endif > \echo NO > > sh> ./psql < test.sql > SET > # ok > unrecognized value

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Fabien COELHO
Consolidated Fabien's TAP test additions with v7, in case anyone else wants to be reviewing. Patch applies (with "patch"), make check ok, psql tap test ok. I did some more tests. I found a subtlety that I missed before: when running under ON_ERROR_STOP, messages are not fully consistent:

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Corey Huinker
On Mon, Feb 6, 2017 at 2:32 PM, Fabien COELHO wrote: > > Do you think the TAP tests would benefit from having the input described >> in a q(...) block rather than a string? >> > > My 0.02€: Not really, so I would not bother. It breaks perl indentation > and logic for a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Fabien COELHO
Do you think the TAP tests would benefit from having the input described in a q(...) block rather than a string? My 0.02€: Not really, so I would not bother. It breaks perl indentation and logic for a limited benefit. Maybe add comments if you feel that a test case is unclear. -- Fabien.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Corey Huinker
On Mon, Feb 6, 2017 at 11:21 AM, Corey Huinker wrote: > >> Find attached a small patch to improve tap tests, which also checks that >>> psql really exited by checking that nothing is printed afterwards. >>> >> >> > Do you think the TAP tests would benefit from having the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Corey Huinker
> > > Find attached a small patch to improve tap tests, which also checks that >> psql really exited by checking that nothing is printed afterwards. >> > > Do you think the TAP tests would benefit from having the input described in a q(...) block rather than a string? q(\if false \echo a \elif

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Fabien COELHO
Find attached a small patch to improve tap tests, which also checks that psql really exited by checking that nothing is printed afterwards. . It is better with the attachement. -- Fabien.diff --git a/src/bin/psql/t/001_if.pl b/src/bin/psql/t/001_if.pl index 68c9b15..a703cab 100644 ---

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-06 Thread Fabien COELHO
# elif error "\\if false\n\\elif error\n\\endif\n" # ignore commands on error (stdout must be empty) "\\if error\n\\echo NO\n\\else\n\\echo NO\n\\endif\n" Those are already in the regression (around line 2763 of expected/psql.out), are you saying we should have them in TAP as well?

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-05 Thread Corey Huinker
> > Hmmm. ISTM that control-c must at least reset the stack, otherwise their > is not easy way to get out. What can be left to another patch is doing a > control-C for contents and then another one for the stack when there is no > content. > And so it shall be. > - put Fabien's tap test in

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-04 Thread Fabien COELHO
Hello Corey, 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

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-04 Thread Corey Huinker
On Sat, Feb 4, 2017 at 11:53 AM, Corey Huinker wrote: > 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

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-04 Thread Corey Huinker
> > 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

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-04 Thread Corey Huinker
> > I noticed that the "barking" is conditional to "success". ISTM that it > should always "bark" in interactive mode, whether success or not. > "success" in those cases means "the expression was a valid boolean", and non-success cases (should) result in an error being printed regardless of

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-04 Thread Daniel Verite
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

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Fabien COELHO
A few comments about v5. New patch. Patch applies (with patch, I gave up on "git apply"). Make check ok. Psql tap test ok. Highlights: - Interactive barking on branching state changes, commands typed while in inactive state I noticed that the "barking" is conditional to "success". ISTM

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Corey Huinker
On Fri, Feb 3, 2017 at 7:42 PM, Jim Nasby wrote: > Since the current consensus is to be very verbose about \if, this is > obviously a non-issue. Maybe worth adding a 'I' case to %R, but no big deal > if that doesn't happen. I think we left the door open to a separate

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Jim Nasby
On 2/2/17 4:39 PM, Corey Huinker wrote: On Wed, Feb 1, 2017 at 4:58 PM, Jim Nasby > wrote: I think the issue here is that the original case for this is a user accidentally getting into an \if and then having no clue what's

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Robert Haas
On Fri, Feb 3, 2017 at 4:24 PM, Corey Huinker wrote: > That might be what we end up doing. I'm willing to see how unwieldy it gets > before rolling back to "endif: peace out". All I'm saying is, give peace a chance. :-) > The state logic has stuff to do anyway, so for

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Corey Huinker
On Fri, Feb 3, 2017 at 3:49 PM, Robert Haas wrote: > On Fri, Feb 3, 2017 at 11:08 AM, Corey Huinker > wrote: > > I could bulk up the error message on if/elif like such: > > > > if: true, executing commands. > > if: false, ignoring commands until

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Robert Haas
On Fri, Feb 3, 2017 at 11:08 AM, Corey Huinker wrote: > I could bulk up the error message on if/elif like such: > > if: true, executing commands. > if: false, ignoring commands until next \else, \elif, or \endif. > if: error, ignoring all commands until next \endif >

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Corey Huinker
On Fri, Feb 3, 2017 at 12:20 PM, Daniel Verite wrote: > If we add the functionality that Ctrl+C also exits from branches, > we could do it like the shell does Ctrl+D for logout, that is it > logs out only if the input buffer is empty, otherwise it does > the other

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Daniel Verite
Corey Huinker wrote: > I meant in the specific psql-context, does it do anything other > than (attempt to) terminate sent-but-not-received SQL queries? It cancels the current edit in the query buffer, including the case when it spans multiple lines. If we add the functionality that

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Tom Lane
Corey Huinker writes: > Well played (again). That one ranks up there with "and don't call me > Shirley." I meant in the specific psql-context, does it do anything other > than (attempt to) terminate sent-but-not-received SQL queries? It also flushes the input buffer. I

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Corey Huinker
> > Can anyone think of a reason why Ctrl-C would be a bad idea? If not I'll >> start looking into it, as I'm not presently aware of what it is used for. >> > > Not me. > > Wikipedia, which holds all the knowledge in the universe, says: "In many > command-line interface environments, control-C is

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Fabien COELHO
I could bulk up the error message on if/elif like such: [...] Looks ok to me. Can anyone think of a reason why Ctrl-C would be a bad idea? If not I'll start looking into it, as I'm not presently aware of what it is used for. Not me. Wikipedia, which holds all the knowledge in the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Corey Huinker
On Fri, Feb 3, 2017 at 7:24 AM, Fabien COELHO wrote: > > Hello Erik, > > Still, it would be an improvement to be able to break out of an inactive >> \if-branch with Ctrl-C. >> > > Yes. > > '\endif' is too long to type, /and/ you have to know it. >> > > Yep. \if is shorter

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Fabien COELHO
2. Inside an \if block \q should be given precedence and cause a direct exit of psql (or at the very least exit the if block(s)), as in regular SQL statements (compare: 'select * from t \q' which will immediately exit psql -- this is good. ) One use case if to be able to write "\if ... \q

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Fabien COELHO
Hello Erik, Still, it would be an improvement to be able to break out of an inactive \if-branch with Ctrl-C. Yes. '\endif' is too long to type, /and/ you have to know it. Yep. \if is shorter but has been rejected. Ctrl-C should be the way out. 2. Inside an \if block \q should be given

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-03 Thread Erik Rijkers
On 2017-02-03 08:16, Corey Huinker wrote: 0001.if_endif.v5.diff 1. Well, with this amount of interactive output it is impossible to get stuck without knowing :) This is good. Still, it would be an improvement to be able to break out of an inactive \if-branch with Ctrl-C. (I noticed that

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-02 Thread Corey Huinker
On Fri, Feb 3, 2017 at 12:57 AM, Fabien COELHO wrote: > > Hello Corey, > > Glad you like the barking. I'm happy to let the prompt issue rest for now, >> we can always add it later. >> >> If we DID want it, however, I don't think it'll be hard to add a special >> prompt

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-02 Thread Fabien COELHO
Hello Corey, Glad you like the barking. I'm happy to let the prompt issue rest for now, we can always add it later. If we DID want it, however, I don't think it'll be hard to add a special prompt (Thinking %T or %Y because they both look like branches, heh), Ah!:-) T may stand for Tree, but

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-02 Thread Corey Huinker
> > > On reflection, it seems fairly improbable to me that people would use > \if and friends interactively. They're certainly useful for scripting, > but would you really type commands that you know are going to be ignored? > I'm thinking the one use-case is where a person is debugging a

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-02-02 Thread Tom Lane
Corey Huinker writes: >> As it is, I've added interactive mode psql_error notifications about the >> resulting branching state of any branching commands, and any attempt to >> send non-branching commands or queries while in an inactive branch will >> genera