On Mon, Oct 12, 2009 at 01:49:40PM -0400, Jay Pipes wrote:
> Here is relevant piece of the current proto:
>
> message Field {
> ...
> message FieldOptions {
> optional string default_value = 1;
> optional string update_value = 2;
> optional bool default_null = 3 [default = false];
> optional bytes default_bin_value = 4;
>
> optional int32 length = 100; /* TODO: should go away */
> }
> ...
> optional FieldOptions options = 4;
>
> Here is a proposed modification which would allow for a vast number of
> functions to be used as defaults:
>
> message Field {
> ...
> message FieldDefault {
> enum FieldDefaultType {
> CONSTANT = 0;
> FUNCTION = 1;
> /* possible FIELD later on... */
> }
> required DefaultType type = 1; /* The type of the default value */
> required bytes default_value = 2; /* The actual value */
> repeated bytes args = 3; /* Array of function arguments */
> }
> ...
> optional FieldDefault default = 4;
> }
>
> The above would allow a fairly future-proof method of constructing
> variable defaults which could include functions with any number of
> arguments.
why this (more complex) structure instead of just the norm which is
default_value being an expression? (with the "bug" of currently just
being constant or "NOW()").
The only reason there is the default_bin_value there is that we can/need/should
support wacky things like a default value of a series of null bytes.
> During mysql_insert(), having such a structure in the Field message
> would allow us to easily create an appropriate Item_string or Item_func
> depending on the value of default.type.
We should have the ability for the engines to take over responsibility
for some/all default values.
--
Stewart Smith
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
