Borrowing from the fine Answer mentioned above in comments, or at least the question it hung under, (and keeping its funny custom error message),
I give this Answer below:
Schema
CREATE TABLE STUDENT
( StudentID int(8) not null primary key, -- 8 is display width, otherwise meaningless. It is an int
Password CHAR(15) NOT NULL
);
Trigger
drop trigger if exists `STUDENT_SomeTrigger`;
DELIMITER $$
CREATE TRIGGER `STUDENT_SomeTrigger`
BEFORE INSERT ON `STUDENT`
FOR EACH ROW
BEGIN
DECLARE msg varchar(1000);
IF (New.StudentId < 10000000 or New.StudentId > 99999999) THEN
# it is not 8 digits, don't allow it
# note, leading zeros don't count!
# you made it an int (well you called it NUMERIC, same thing)
# if you mean for it to be a string, then do so
set msg = "DIE: You broke the rules... I will now Smite you, hold still...";
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = msg;
END IF;
-- Do any other code here you may want to occur if it's all OK or leave blank it will be
-- skipped if the above if is true
END
$$
DELIMITER ;
Test it
insert STUDENT(StudentID,password) values (12345678,'OpenSesame');
-- 1 row(s) affected
insert STUDENT(StudentID,password) values (1234567,'No Insert');
-- Error Code: 1644. DIE: You broke the rules... I will now Smite you, hold still...
insert STUDENT(StudentID,password) values (123456789,'No Insert');
-- Error Code: 1644. DIE: You broke the rules... I will now Smite you, hold still...
insert STUDENT(StudentID,password) values (87654321,'Ok also');
-- 1 row(s) affected
Look at data
select * from STUDENT;
+-----------+------------+
| StudentID | Password |
+-----------+------------+
| 12345678 | OpenSesame |
| 87654321 | Ok also |
+-----------+------------+
That is how a trigger would achieve your requirement of ID sizing. That is, the ID must be 8 digits.
So that is why I marked it as a duplicate, but you wanted to see it in action, which is understandable.
Please see the Manual page on Trigger Syntax.
Please see the Manual page on Signal. A long page on it. A quick excerpt:
SIGNAL is the way to “return” an error. SIGNAL provides error
information to a handler, to an outer portion of the application, or
to the client. Also, it provides control over the error's
characteristics (error number, SQLSTATE value, message). Without
SIGNAL, it is necessary to resort to workarounds such as deliberately
referring to a nonexistent table to cause a routine to return an
error.