> In which case you will get two different results.
I get your point, code can't compensate bad programing.
I'd say I'll offer two alternative versions of prepare (dynamic references vs static values) and emphasize on a do which does the execution after a prepare_cached right away.
> Maybe calling xprepare twice without calling xexecute should be forbidden (die),
Nah, but I can throw a warning if two dynamic prepares bind the same refs.
> but they can also do that across sessions, if the optimizer sees the exact same request prepared again,
Does it mean that prepare_cached from DBI is not necessary anymore?
In any case I think that "deinterpolated" templates with placeholders are easier to cache than queries with hardcoded $names.
Again, my emphasis ATM is on the "deinterpolater" and not the SQL api.
I could think of many use cases, like generating / refactoring to printf or various HTML templates.
Cheers Rolf
(addicted to the Perl Programming Language and ☆☆☆☆ :)
Wikisyntax for the Monastery
In reply to Re^6: RFC: Placeholder creation for SQL statements
by LanX
in thread RFC: Placeholder creation for SQL statements
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |