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

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