Re: Feature discussion: Should syntax errors abort a transaction?

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
>

Responses

Browse pgsql-general by date

  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?