| From: | Edson Richter <edsonrichter(at)hotmail(dot)com> |
|---|---|
| To: | Scott Marlowe <scott(dot)marlowe(at)gmail(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 19:09:17 |
| Message-ID: | BLU0-SMTP61666259B69FDDAA7AA48FCFFF0@phx.gbl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
And I will be pleased that data is gone! I really did not expect anything but this.
If I need such tolerant behavior, then this shall be a feature of my special app, not a feature of the database... If the developer does not know how to write sql, then is time to learn. If the problem is the dynamic generated Sql, then I must write more test cases to cover these new scenarios. But IMHO, database must fail always (syntax or not...).
Regards,
Edson
Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> escreveu:
>On Tue, Jun 19, 2012 at 8:50 AM, Edson Richter <edsonrichter(at)hotmail(dot)com> wrote:
>> 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...
>
>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.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martín Marqués | 2012-06-19 19:31:44 | Special ORDER BY |
| Previous Message | Steve Crawford | 2012-06-19 17:28:39 | Re: db server processes hanging around |