Rafal Pietrak <rafal@zorro.isa-geek.com> writes:
> The point is, that SQL syntax errors are so obviusly different from
> execution errors, that noting this distinction should not raise any
> ambiguity.
I beg to disagree. Typos can manifest themselves as execution errors
just as well as syntax errors.
You are probably thinking that we could behave differently if the error
was detected by the lexer, or perhaps the lexer + grammar, rather than
later on. But those boundaries are purely implementation artifacts,
and the division of labor isn't always obvious, especially to people not
steeped in the innards of PG. Users are going to be confused (and
unhappy) if some errors roll back their transaction while other
not-obviously-different ones don't.
As an example, suppose you fat-finger '-' for '=' in UPDATE:
UPDATE tab SET col - 42 WHERE ...
This is going to draw a grammar error. But make the same mistake
a few tokens later:
UPDATE tab SET col = 42 WHERE key - 42;
and now you will get a pretty late-stage parse analysis failure,
since it'll bleat that the argument of WHERE isn't boolean. Users
are definitely not going to understand why the former doesn't kill
their transaction but the latter does. Or, if we solve that problem
by saying that no parse-analysis failure kills the transaction,
where does that stop? The boundaries between parse analysis, planning,
and execution are even squishier and more arbitrary (from a naive user's
standpoint) than the ones earlier in the process.
regards, tom lane
