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: | Raw Message | Whole Thread | 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? |