> > My point is that examples about one thing can be interpreted as example > for other things which is also done in the example, so it is better to do > everything right. >
Fair enough. I'll rewrite the examples to use pk lookups. I doubt the query plan for those will change much in the future. > Hmmm. Copy-pasting is bad enough, and "when the other patch is committed" > is an unknown, so I would still suggest to fix obvious defects at least (eg > dead code which may result in compiler warnings, inconsistent comments...). > It was do that or pause this work until that unknown was resolved. > > My point was that you must at least push something, otherwise both > branches are executed (!), and some commands could be attached to > upper-level conditions: > > > As for which state is pushed, it is indeed debatable. I do think that > pushing ignore on errors is a better/less risky behavior, but other people' > opinion may differ. +1 > > > On "else" when in state ignored, ISTM that it should remain in state >>> ignore, not switch to else-false. >>> >> >> That's how I know if this is the first "else" I encountered. >> > > Ok, my mistake. Maybe expand the comment a little bit if appropriate. +1 > > As I recall, history is only for interactive mode. If I really typed > something, I'm expecting to get it by visiting previous commands, because I > certainly do not want to retype it again. > > For your above example, maybe I would reedit the clause definition, then > want to execute the delete. Good points, and history does save the string with the variable in it, not the resolved string that was sent (or not sent) to the server.
