Something that I believe warrants reconsideration is prepared statement
handling. I am aware that prepared statements were handled badly in
MySQL, but that doesn't mean they are a bad idea. Prepared statements
enable a compiled statement cache, intrinsically much faster than
parsing, compiling, and optimizing the same statements over and over and
over -- no matter how fast the parser and optimizer are, not parsing and
optimizing is faster.
Prepared statements also encourage the use of parameters, simplifying
programming and eliminating the risk of SQL insertion. But other than
faster, easier, and safer, they don't have a lot more going for them.
If anyone is at all interested, the Falcon native SQL engine has a very
clean reference implementation. In a nutshell, DDL is interpreted from
the syntax tree while DML is compiled into a shared CompiledStatement
and either Statement or PreparedStatement instance. CompiledStatements
with parameters are added to the compiled statement cache, others are
deleted after use (no point is caching one-time use statements). When a
new statement comes in, it is compared for exact (!) string equality
against the set of compiled statements. For each match, a list of
unqualified object names must be checked against the current default
database/schema. For a hit, it is also necessary to validate access
permission (assuming you still have access permissions).
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
