There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I would
neverwant half job done. Thia is the purpose of transactions: or all or nothing...
Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>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
>
>--
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general
>