Stewart Smith wrote:
On Wed, Oct 07, 2009 at 04:17:12PM -0700, Brian Aker wrote:
On Oct 7, 2009, at 3:53 PM, Stewart Smith wrote:
we can also easily do this for any field, not just DATE.

We currently even do this for TIMESTAMP DEFAULT NOW(), it puts the
"NOW()" function in the table proto (and then string compares it to pull
it out into the unireg_check crud in the server).
So just an optional string to match against a function?

yeah... in the proto it's as a "expression to be evaluated" currently
only supporting NOW() :)

What about allowing all non-aggregate functions?

perhaps also disallowing arguments that have to be further evaluated
(e.g. you can't have "FIELDA DEFAULT MD5(FIELDB)" but you could have
"FIELDA DEFAULT MD5("PANTS")") ?
See... this is why it gets tricky. I don't know that "one size fits all" for functions.

yeah...

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.

During parsing of the CREATE TABLE statement, code such as the following could be used in sql_yacc.yy:

column_default:

DEFAULT string
{
  message::Field::FieldDefault *default= $<field>->mutable_default();
  default->set_type(message::Field::FieldDefault::CONSTANT);
  default->set_default_value($2->val_str()->c_ptr());
  $$= default;
}
DEFAULT string LPAREN arg_list RPAREN
{
  message::Field::FieldDefault *default= $<field>->mutable_default();
  string func_name(default->set_value($2->val_str()->c_ptr()));
  if (! functionCanBeDefault(func_name))
  {
    my_error(ER_FUNC_NO_DEFAULT, ...);
    YYABORT();
  }
  else
  {
    default->set_type(message::Field::FieldDefault::FUNCTION);
    default->set_default_value(func_name.c_str());
    addArgListToDefaultFunction(default, $4);
  }
  $$= default;
}

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.

Cheers,

Jay

_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to