wer redet denn von Syntax Fehlern?
Das tut mir aber leid, dass du nicht weisst das es ein “vor dem Insert” gibt … wie konnten sie bloss SAVEPOINT realisieren - wieder eine Fkt die es garnicht geben kann …
wie es in den Wald schallt
… nimms nicht so ernst …
zum Thema nochmal …
ich kann so recht haben, wie ich will - mit den TX - das bringt mir nix - weil PG davon nicht besser wird - und uns nicht geholfen
Wenn ich auch nur das leiseste Gefühl haette, dass ihr beiden “vernuenfig” Diskutieren wollt, dann liese sich sehr wahrscheilich sogar eine interessante TECHNISCHE Begruendung dafuer liefern, warum PG so funktioniert wie es funktioniert. D.h. ich habe so eine leise Ahnung davon warum es so ist.
Weisst du - wenn ihr sagt “nutzt SAVEPOINT” - ist das eine Sache - Wenn ihr sagt “nutzt SAVEPOINT weil das ist das beste der Welt und alle anderen machen es falsch” kann ich das nicht einfach so stehen lassen. Weil <-DAS Quatsch ist.
Schau mal … SAVEPOINT ist eine Lösung fuer eine Art “subtransactions” … spinnt man diese “Interpretation” mal weiter, dann sehe ich bei DML-Kommando auch lauter subtransactions. Nirgends steht geschrieben, dass das nicht so sein darf. So ziemlich jedes gängige DBMS hat es so umgesetzt - weils naheliegend und nachvollziehbar und eben NICHT FALSCH ist. An anderen Stellen in PG funktioniert es ja auch wunderbar. Ich kann mich immer drauf verlassen, das alles nach dem UPDATE, DELETE, INSERT konsistent ist - egal wieviele Mrd Trigger aufgerufen wurden - weils als TX abgearbeitet wird.
Eure Argumentation ist wie ich schon mehrfach erwähnte auch nicht Konsistent - ihr sagt bei einem Fehler ist die TX per definition ungueltig - wie soll dann SAVEPOINT funktionieren? das ist innerhalb einer TX … es passiert ein Fehler ? In welchen SAVEPOINT der TX soll ich denn zurueckrollen - wenn sie garnichtmehr existieren kann ? siehe oben ?
Gut - es ist aber wie es ist - Performance wäre z.B. ein akzeptables und nachvollziehbares Argument, weil der Aufwand für explizite SAVEPOINTS präsenter ist als ähnlicher (ich manchen fällen gleich grosser) für jede Operation. Dieses Argument haette die gleiche Qualitaet wie der gänzliche Verzicht von TX z.B. bei MyISAM - da sagt auch niemand, weils das beste der Welt ist - alternativ gibts andere table-typen …
so kann man argumentieren …