* PREPARE OR REPLACE...
This would be an incredibly useful command since there's no way of _checking_ in advance that a name is already used as a prepared statement...
A check would be nice (and I've asked about it before) but it's
really not a lot of jumping through hoops since each connection has
it's own "namespace" of prepared statements. Since they last until
an explicit deallocate, the simple use of unique names makes it
fairly easy on the application side.
Depends. I've got some report templating code that just replaces some parameters and executes sql embedded in the template.
Replacing the parameters is neater if I use prepare/execute, but if the sql gets executed again of course I get an error. The only way to know if there is a PREPARE is to regexp the sql text - yuck.
Now, you might argue I should make my report code handle prepare directly, then I'd know if I'd defined it or not. As it happens, that's not the way things stand though.
-- Richard Huxton Archonet Ltd
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
