| From: | Edson Richter <edsonrichter(at)hotmail(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> | 
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: Feature discussion: Should syntax errors abort a transaction? | 
| Date: | 2012-06-19 14:50:49 | 
| Message-ID: | BLU0-SMTP2057B1631D9A0589ACA8C3ECFFF0@phx.gbl | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I would never want half job done. Thia is the purpose of transactions: or all or nothing...
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:
>Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)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(at)postgresql(dot)org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2012-06-19 15:49:39 | Re: Feature discussion: Should syntax errors abort a transaction? | 
| Previous Message | Rainer Pruy | 2012-06-19 14:25:02 | Re: Feature discussion: Should syntax errors abort a transaction? |