No se entiende muy bien lo que dices. Trata de no escribir en SMS, aquí tienes tiempo y espacio para hacerlo bien, y mientras mejor escribas, más fácil es entender tu problema.
Te recalco lo que dije antes: No existe un lenguaje PL/SQL estandar. No se ha definido nada y cada DBMS implementa el que quiere, poniéndole o sacándole cosas como se les ocurre. A eso tienes que sumarle que también le meten cosas que son extensiones que al ANSI-SQL ya le han puesto a las consultas, lo que lleva a que el panorama se vuelva peor.
Consejo: Cuando empieces a usar un DBMS busca el manual de referencia en linea. Todo lo que necesitas saber está allí. En el caso de MySQL hay dos capítulos:
Stored Procedures y
Triggers, que tienen lo suficiente como para empezar.
Lo principal es:
- Las variables locales de un trigger no llevan "@". Sólo cierto tipo especial de variables usan ese prefijo.
- Los triggers (y los SP) deben cargarse como un sólo objeto. Cuando tienen más de una línea eso se hace cambiándole momentáneamente al MySQL el delimitador de sentencias por defecto (el ";") con la cláusula DELIMITER. Esto sólo se hace cuando usas la consola o lo cargas desde un script. No se hace cuando lo cargas con un lenguaje (PHP, ASP, o lo que sea).
- Los trigger sólo tienen datos de entrada, no poseen datos de salida, no son opcionales, no pueden interrumpirse ni evitarse condicionalmente.
- Como no devuelven datos, no sirven para determinar estados de error o confirmación de ningún tipo.
- Solamente se usan cuando hay una tarea que siempre se debe realizar ante un evento INSERT/UPDATE/DELETE sobre una tabla.
- No se admiten anidamientos ni recursividades. No pueden realizar una tarea de INSERT/UPDATE/DELETE sobre la misma tabla donde se definen, ni tampoco sobre una tabla que tenga definida una acción contra la propia del TRIGGER (recursividad).
- Para acceder a los datos que están entrando o los que ya existían en el registro afectado por el evento INSERT/UPDATE/DELETE se usan pseudovariables NEW y OLD que sólo existen dentro del TRIGGER.
Hay algunos otros considerandos, pero por el momento es suficiente.
Tu trigger no puede definirse en MySQL porque se trata de un trigger de ejecución condicional, que en MySQL no existen. Lo que tu quieres hacer se debe realizar en un stored procedure.
Como tip adicional te diría que si lo que quieres es validar la longitud del nombre ingresado por el usuario,
eso no se hace en la base de datos (es un desperdicio de tiempo, conexión y capacidades), sino que
se hace en la aplicación, poniéndole las validaciones en el formulario de ingreso de datos.
Plantear que las validaciones las haga la base es un vicio de los programadores, que no quieren tener que hacer esa parte (las validaciones) porque les resultan engorrosas. ¡Por supuesto que lo son! Pero eso no quiere decir que no sea muchísimo más eficiente hacerlo en la capa de negocios que en la base, a donde deberían llegar los datos ya depurados...