Re: Feature discussion: Should syntax errors abort a transaction? - Mailing list pgsql-general

From Edson Richter
Subject Re: Feature discussion: Should syntax errors abort a transaction?
Date
Msg-id BLU0-SMTP2057B1631D9A0589ACA8C3ECFFF0@phx.gbl
Whole thread Raw
Responses Re: Feature discussion: Should syntax errors abort a transaction?  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
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
>

pgsql-general by date:

Previous
From: Rainer Pruy
Date:
Subject: Re: Feature discussion: Should syntax errors abort a transaction?
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: Feature discussion: Should syntax errors abort a transaction?