Update einer Chatfunktion

[dedlfix]

Tach!

MySQL hat zwei native Interfaces um mit Prepared Statements zu arbeiten. Es gibt eine Schnittstelle aufbauend auf dem Binärprotokoll und eine menschenlesbare Schnittstelle in MySQL-Syntax.

Ach, diese (verlinkte) meinst du. Die ist dafür da, den Vorteil des Preparieren und nicht immer wieder neu parsen Müssens in gescriptetem SQL zu haben, also in Stored Programs (Procedures und Functions). Die hatte ich jetzt gar nicht auf dem Radar, weil sie noch seltener als Stored Programs selbst Verwendung findet (Seltenheit bezogen auf die gefühlte Verwendung der MySQL-Features im typischen Webumfeld).

Beide Varianten müssen gewährleisten, dass Nutzdaten nicht versehentlich als Steuerdaten interpretiert werden.

Mir scheint, dass du dich hier irrst. Bei der verlinkten Variante werden beim Execute Variablennamen angegeben. Wie die Werte in die Variablen kommen ist nicht das Problem der Prepared Statements. Dem Execute können nur Variablen und keine Literale übergeben werden. Und selbst wenn, wäre das Maskieren im Literal ebenfalls kein Problem des Prepared Statements an sich, ebensowenig wie wenn für das Variablenbefüllen Literale notwendig sind. Die eigentlichen Werte in den Variablen müssen im Rohformat vorliegen. Ich sehe da weder ex- noch implizites Maskieren.

Unter "Emulation" verstehe ich nach jetzigem Kenntnisstand noch etwas anderes, [...]

In dem Punkt sind wir uns einig.

dedlfix.