been shrunk to 1999 to 2001.
* d, with values ranging from 2017 to 2019, where only the lower value falls
within the portion to be deleted, has been shrunk to 2018 to 2019.

The DELETE FOR PORTION statement has the following restrictions

* The FROM...TO clause must be constant
* Multi-delete is not supported

If there are DELETE or INSERT triggers, it works as follows: any matched row
is deleted, and then one or two rows are inserted. If the record is deleted
completely, nothing is inserted.

Updating by Portion
-------------------

The UPDATE syntax now supports UPDATE FOR PORTION, which modifies rows based
on their occurrence in a range:

To test it, first populate the table with some data:

TRUNCATE t1;

INSERT INTO t1 (name, date_1, date_2) VALUES
  ('a', '1999-01-01', '2000-01-01'),
  ('b', '1999-01-01', '2018-12-12'),
  ('c', '1999-01-01', '2017-01-01'),
  ('d', '2017-01-01', '2019-01-01');

SELECT * FROM t1;
+------+------------+------------+
| name | date_1     | date_2     |
+------+------------+------------+
| a    | 1999-01-01 | 2000-01-01 |
| b    | 1999-01-01 | 2018-12-12 |
| c    | 1999-01-01 | 2017-01-01 |
| d    | 2017-01-01 | 2019-01-01 |
+------+------------+------------+

Then run the update:

UPDATE t1 FOR PORTION OF date_period
 FROM '2000-01-01' TO '2018-01-01'
SET name = CONCAT(name,'_original');

SELECT * FROM t1 ORDER BY name;
+------------+------------+------------+
| name       | date_1     | date_2     |
+------------+------------+------------+
| a          | 1999-01-01 | 2000-01-01 |
| b          | 1999-01-01 | 2000-01-01 |
| b          | 2018-01-01 | 2018-12-12 |
| b_original | 2000-01-01 | 2018-01-01 |
| c          | 1999-01-01 | 2000-01-01 |
| c_original | 2000-01-01 | 2017-01-01 |
| d          | 2018-01-01 | 2019-01-01 |
| d_original | 2017-01-01 | 2018-01-01 |
+------------+------------+------------+

* a is unchanged, as the range falls entirely out of the specified portion to
be deleted.
* b, with values ranging from 1999 to 2018, is split into two rows, 1999 to
2000 and 2018-01 to 2018-12.
* c, with values ranging from 1999 to 2017, where only the upper value falls
within the portion to be deleted, has been shrunk to 1999 to 2001.
* d, with values ranging from 2017 to 2019, where only the lower value falls
within the portion to be deleted, has been shrunk to 2018 to 2019. 
* Original rows affected by the update have "_original" appended to the name.

The UPDATE FOR PORTION statement has the following limitations:

* The operation cannot modify the two temporal columns used by the time period
* The operation cannot reference period values in the SET expression
* FROM...TO expressions must be constant

WITHOUT OVERLAPS
----------------

MariaDB starting with 10.5.3
----------------------------
MariaDB 10.5 introduced a new clause, WITHOUT OVERLAPS, which allows one to
create an index specifying that application time periods should not overlap.

An index constrained by WITHOUT OVERLAPS is required to be either a primary
key or a unique index.

Take the following example, an application time period table for a booking
system:

CREATE OR REPLACE TABLE rooms (
 room_number INT,
 guest_name VARCHAR(255),
 checkin DATE,
 checkout DATE,
 PERIOD FOR p(checkin,checkout)
 );

INSERT INTO rooms VALUES 
 (1, 'Regina', '2020-10-01', '2020-10-03'),
 (2, 'Cochise', '2020-10-02', '2020-10-05'),
 (1, 'Nowell', '2020-10-03', '2020-10-07'),
 (2, 'Eusebius', '2020-10-04', '2020-10-06');

Our system is not intended to permit overlapping bookings, so the fourth
record above should not have been inserted. Using WITHOUT OVERLAPS in a unique
index (in this case based on a combination of room number and the application
time period) allows us to specify this constraint in the table definition.

CREATE OR REPLACE TABLE rooms (
 room_number INT,
 guest_name VARCHAR(255),
 checkin DATE,
 checkout DATE,
 PERIOD FOR p(checkin,checkout),
 UNIQUE (room_number, p WITHOUT OVERLAPS)
 );

INSERT INTO rooms VALUES 
 (1, 'Regina', '2020-10-01', '2020-10-03'),
 (2, 'Cochise', '2020-10-02', '2020-10-05'),
 (1, 'Nowell', 'âKæ†