Hi!
On Nov 2, 2009, at 6:37 AM, Jay Pipes wrote:
InnoDB is not the only engine other than MyISAM, of course :) Paul,
would this apply to PBXT? Toru, could you comment on BlitzDb?
The question is "does the engine have its own format". If the engine
has its own types then it will store the data in whatever type most
fits. If the engine just writes out the row format then it matters how
it calls pack (though possibly not with decimal). Writing out the raw
format is a bit dangerous though since any changes to the memory
format will leave you with junk.
Once we have pluggable types it will go one of a few ways for any
engine writer:
1) They add the ability to store the type in a native format (aka...
they extend their engine).
2) They reject the creation of a table with a type they do not handle.
3) They force a save (probably in a blog). This BTW is how NDB handles
GEOMETRY types in MySQL.
All of the "saves space on disk" is about MyISAM. AKA... MyISAM has no
native formats so the upper end of the server is slave to whatever
changes are done for MyISAM. The BIT field type was a perfect example
of this (and it caused the in-memory to behave differently for
different engine).
Any engine should be abstracting the Field format in the future to
some native type.
Brian, could you expand/elaborate on what you mean by "putting a
priority on the static field array in field.cc"?
Look at field_types_merge_rules in field.cc. That fixed array forces
us into:
1) Any new type must have an update to this (making pluggable
impossible/a hack).
2) Defeats our ability to toss an error when a merge of a type really
should just toss an error. AKA.. GEOM to a String. What would that mean?
Cheers,
-Brian
Cheers,
-Brian
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
