On Sun, Apr 01, 2001 at 12:10:18PM +0300, Michael Widenius wrote:
> Yes this should work ok as long as you don't do that in a loop!
> The reason is that each new_field allocates space which will not be
> freed until the SQL statement is completed.
I was planning on deleting them after each row or after each query,
depending on how constant table->field's pointers are. I want to
minimize the scanning of table->field and the creation of old_fields.
I'd prefer to cache pointers to fields and to cache the old_fields.
When do the Fields pointed to table->field get exchanged for new fields?
In other words, when is it safe, if ever, to cache pointers to those
fields in List<Field> containers so the triggers don't need to rescan
that list each row or each query?
The reason I ask about the constancy of table->field is that is seems to
be pointing at one set of Field objects when attach_triggers() is called
DBUG_PRINT("info", ("inserting table %p into the cache", table));
and a different set when the triggers fire in mysql_update(). I've
started walking through it in gdb, but does the table->field array
ever become stable for the lifetime of the table?
As a side question: how does mysqld pack variable length columns into
record and record such that move_field() works?
> I could put this in our
> Patches section on the web page to make it easily accessible.
That would be just fine. I'm also thinking that it'd be nice to combine
it with the embedded perl work going on and see if we can get Perl