The INSERT, DELETE, and UPDATE statement interface

The following figure shows the order in which the database server executes purpose functions to insert, delete, or update a row at a specific physical address. The physical address consists of fragment identifier and row identifier.

Figure 1. INSERT, DELETE, or UPDATE by row address

Flowchart shows am_open fragment pointing to a box which contains am_insert row, am_delete row, or am_update row. This box points to am_close fragment.

The following figure shows the order in which the database server executes purpose functions if the insert, delete, or in-place update has an associated WHERE clause.

Figure 2. INSERT, DELETE, or UPDATE in a subquery

Flowchart shows am_scancost pointing to am_open, which points to am_beginscan, which points to am_getnext. If the am_getnext returns MI_ROWS, the scan executes am_insert or am_delete or am_update, and then executes am_getnext again. If am_getnext returns MI_NO_MORE_RESULTS, the scan continues to am_endscan, which points to am_close.

The following figure shows the more complicated case in which am_getnext returns multiple rows to the database server. In either case, the database server calls am_insert, am_delete, or am_update once per row.

Figure 3. Returning multiple rows that qualify for INSERT, DELETE, or UPDATE

Flowchart shows am_scancost pointing to am_open, which points to am_beginscan, which points to am_getnext. If the am_getnext returns MI_ROWS, the diagram points to a box that contains am_insert, am_delete, or am_update. This box points to another box that says "nextrow = norows?" If Yes, the scan returns to am_getnext. If No, the scan returns back to the box that contains am_insert, am_delete, or am_update. If am_getnext returns MI_NO_MORE_RESULTS, the scan continues to am_endscan, which points to am_close.