Обсуждение: Re: Feature discussion: Should syntax errors abort a transaction?
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 >
On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter@hotmail.com> wrote: > There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I wouldnever want half job done. Thia is the purpose of transactions: or all or nothing... This this this, and again, this. Imagine: begin; insert into tableb selcet * from tableb; truncate tableb; commit; What should happen when we get to the error on the second line? Keep going? Boom, data gone because of a syntax error.
On Tue, Jun 19, 2012 at 11:25:24AM -0600, Scott Marlowe wrote:
> On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter@hotmail.com> wrote:
> > There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I
wouldnever want half job done. Thia is the purpose of transactions: or all or nothing...
>
> This this this, and again, this. Imagine:
>
> begin;
> insert into tableb selcet * from tableb;
> truncate tableb;
> commit;
>
> What should happen when we get to the error on the second line? Keep
> going? Boom, data gone because of a syntax error.
I've been lurking, and maybe I should go back to that :-) but I think you misunderstand. The idea is not to ignore or
second-guesstypoes, but to report them without affecting the transaction, and only do this in interactive sessions.
Personally, I like the idea of BEGIN INTERACTIVE, but note I do not offer to do the work.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
On Wed, Jun 20, 2012 at 06:36:09AM -0700, felix@crowfix.com wrote:
> On Tue, Jun 19, 2012 at 11:25:24AM -0600, Scott Marlowe wrote:
> > On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter@hotmail.com> wrote:
> > > There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I
wouldnever want half job done. Thia is the purpose of transactions: or all or nothing...
> >
> > This this this, and again, this. Imagine:
> >
> > begin;
> > insert into tableb selcet * from tableb;
> > truncate tableb;
> > commit;
> >
> > What should happen when we get to the error on the second line? Keep
> > going? Boom, data gone because of a syntax error.
>
> I've been lurking, and maybe I should go back to that :-) but I think you misunderstand. The idea is not to ignore
orsecond-guess typoes, but to report them without affecting the transaction, and only do this in interactive sessions.
>
> Personally, I like the idea of BEGIN INTERACTIVE, but note I do not offer to do the work.
Looks like I should go back to lurking, and do better at it :-(
The discussion began about differentiatng typoes and other errors, which is clearly not easy or obvious, and something
thathas always frustrated me when I find programs which try to do so. Then I saw the idea of BEGIN INTERACTIVE and
lostsight of the discussion.
My apoligies for stepping in so badly.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Em 20/06/2012 11:00, felix@crowfix.com escreveu: > On Wed, Jun 20, 2012 at 06:36:09AM -0700, felix@crowfix.com wrote: >> On Tue, Jun 19, 2012 at 11:25:24AM -0600, Scott Marlowe wrote: >>> On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter@hotmail.com> wrote: >>>> There is also the case of dynamically generated sql statements based on user selection... being syntax or not, I wouldnever want half job done. Thia is the purpose of transactions: or all or nothing... >>> This this this, and again, this. Imagine: >>> >>> begin; >>> insert into tableb selcet * from tableb; >>> truncate tableb; >>> commit; >>> >>> What should happen when we get to the error on the second line? Keep >>> going? Boom, data gone because of a syntax error. >> I've been lurking, and maybe I should go back to that :-) but I think you misunderstand. The idea is not to ignore orsecond-guess typoes, but to report them without affecting the transaction, and only do this in interactive sessions. >> >> Personally, I like the idea of BEGIN INTERACTIVE, but note I do not offer to do the work. > Looks like I should go back to lurking, and do better at it :-( > > The discussion began about differentiatng typoes and other errors, which is clearly not easy or obvious, and somethingthat has always frustrated me when I find programs which try to do so. Then I saw the idea of BEGIN INTERACTIVEand lost sight of the discussion. > > My apoligies for stepping in so badly. > Don't be sorry, your question arrived a great discussion. Nobody is mad about that, is just a matter to have great minds having great discussions! Thansk for bringing that. Does not mean I agree with your point, but the debate is bigger than my personal opinion. I'm certain that something good will arrive from this thread. In time: I believe that "Begin Interactive" is not a good idea. Such behavior shall be built in the interface application, not in database backend... As I stated before, being tolerant or not, or trying to "guess" what user means is a task for the interface. The database must keep the "always safe, always good" policy with data. Regards, Edson.