GRANTpriv_type
[(column_list
)] [,priv_type
[(column_list
)]] ... ON [object_type
] {tbl_name
| * | *.* |db_name
.*} TOuser
[IDENTIFIED BY [PASSWORD] 'password
'] [,user
[IDENTIFIED BY [PASSWORD] 'password
']] ... [REQUIRE NONE | [{SSL| X509}] [CIPHER 'cipher
' [AND]] [ISSUER 'issuer
' [AND]] [SUBJECT 'subject
']] [WITHwith_option
[with_option
] ...]object_type
= TABLE | FUNCTION | PROCEDUREwith_option
= GRANT OPTION | MAX_QUERIES_PER_HOURcount
| MAX_UPDATES_PER_HOURcount
| MAX_CONNECTIONS_PER_HOURcount
| MAX_USER_CONNECTIONScount
REVOKEpriv_type
[(column_list
)] [,priv_type
[(column_list
)]] ... ON [object_type
] {tbl_name
| * | *.* |db_name
.*} FROMuser
[,user
] ... REVOKE ALL PRIVILEGES, GRANT OPTION FROMuser
[,user
] ...
Los comandos GRANT
y
REVOKE
permiten a los adminitradores de
sistemas crear cuentas de usuario MySQL y darles permisos y
quitarlos de las cuentas.
La información de cuenta de MySQL se almacena en las tablas
de la base de datos mysql
. Esta base de
datos y el sistema de control de acceso se discuten
extensivamente en
Capítulo 5, Administración de bases de datos, que puede
consultar para más detalles.
Si las tablas de permisos tienen registros de permisos que
contienen nombres de tablas o bases de datos con mayúsculas y
minúsculas y la variable de sistema
lower_case_table_names
está activa,
REVOKE
no puede usarse para quitar los
permisos. Es necesario manipular las tablas de permisos
directamente. (GRANT
no creará estos
registros cuando está activo
lower_case_table_names
, pero tales
registros pueden haberse creado préviamente a activar la
variable.)
Los permisos pueden darse en varios niveles:
Nivel global
Los permisos globales se aplican a todas las bases de
datos de un servidor dado. Estos permisos se almacenan en
la tabla mysql.user
. GRANT ALL
ON *.*
y REVOKE ALL ON *.*
otorgan y quitan sólo permisos globales.
Nivel de base de datos
Los permisos de base de datos se aplican a todos los
objetos en una base de datos dada. Estos permisos se
almacenan en las tablas mysql.db
y
mysql.host
. GRANT ALL ON
y
db_name
.*REVOKE ALL ON
otorgan y
quitan sólo permisos de bases de datos.
db_name
.*
Nivel de tabla
Los permisos de tabla se aplican a todas las columnas en
una tabla dada. Estos permisos se almacenan en la tabla
mysql.tables_priv
. GRANT ALL
ON
y
db_name.tbl_name
REVOKE ALL ON
otorgan y quian permisos sólo de tabla.
db_name.tbl_name
Nivel de columna
Los permisos de columna se aplican a columnas en una tabla
dada. Estos permisos se almacenan en la tabla
mysql.columns_priv
. Usando
REVOKE
, debe especificar las mismas
columnas que se otorgaron los permisos.
Nivel de rutina
Los permisos CREATE ROUTINE
,
ALTER ROUTINE
,
EXECUTE
, y GRANT
se
aplican a rutinas almacenadas. Pueden darse a niveles
global y de base de datos. Además, excepto para
CREATE ROUTINE
, estos permisos pueden
darse en nivel de rutinas para rutinas individuales y se
almacenan en la tabla mysql.procs_priv
.
La cláusula object_type
se
añadió en MySQL 5.0.6. Debe especificarse como
TABLE
, FUNCTION
, o
PROCEDURE
cuando el siguiente objeto es una
tabla, una función almacenada, o un procedimiento almacenado.
Para usar esta cláusula cuando actualice de una versión
anterior de MySQL a la 5.0.6, debe actualizar las tablas de
permisos. Consulte Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.
Para usar GRANT
o
REVOKE
, debe tener el permiso
GRANT OPTION
, y debe tener los permisos
que está dando o quitando.
Para hacer fácil de quitar todos los permisos, MySQL 5.0 tiene la siguiente sintaxis, que borra todos los permisos globales, de nivel de base de datos y de nivel de tabla para los usuarios nombrados:
REVOKE ALL PRIVILEGES, GRANT OPTION FROMuser
[,user
] ...
Para usar esta sintaxis REVOKE
, debe tener
el permiso CREATE USER
global o el permiso
UPDATE
para la base de datos
mysql
.
Para los comandos GRANT
y
REVOKE
, priv_type
pueden especificarse como cualquiera de los siguientes:
Permiso | Significado |
ALL [PRIVILEGES] |
Da todos los permisos simples excepto GRANT OPTION
|
ALTER |
Permite el uso de ALTER TABLE
|
ALTER ROUTINE |
Modifica o borra rutinas almacenadas |
CREATE |
Permite el uso de CREATE TABLE
|
CREATE ROUTINE |
Crea rutinas almacenadas |
CREATE TEMPORARY TABLES |
Permite el uso de CREATE TEMPORARY TABLE
|
CREATE USER |
Permite el uso de CREATE USER , DROP
USER , RENAME USER , y
REVOKE ALL PRIVILEGES . |
CREATE VIEW |
Permite el uso de CREATE VIEW
|
DELETE |
Permite el uso de DELETE
|
DROP |
Permite el uso de DROP TABLE
|
EXECUTE |
Permite al usuario ejecutar rutinas almacenadas |
FILE |
Permite el uso de SELECT ... INTO OUTFILE y
LOAD DATA INFILE
|
INDEX |
Permite el uso de CREATE INDEX y DROP
INDEX
|
INSERT |
Permite el uso de INSERT
|
LOCK TABLES |
Permite el uso de LOCK TABLES en tablas para las que
tenga el permiso SELECT
|
PROCESS |
Permite el uso de SHOW FULL PROCESSLIST
|
REFERENCES |
No implementado |
RELOAD |
Permite el uso de FLUSH
|
REPLICATION CLIENT |
Permite al usuario preguntar dónde están los servidores maestro o esclavo |
REPLICATION SLAVE |
Necesario para los esclavos de replicación (para leer eventos del log binario desde el maestro) |
SELECT |
Permite el uso de SELECT
|
SHOW DATABASES |
SHOW DATABASES muestra todas las bases de datos |
SHOW VIEW |
Permite el uso de SHOW CREATE VIEW
|
SHUTDOWN |
Permite el uso de mysqladmin shutdown |
SUPER |
Permite el uso de comandos CHANGE MASTER ,
KILL , PURGE MASTER
LOGS , and SET GLOBAL , el
comando mysqladmin debug le permite
conectar (una vez) incluso si se llega a
max_connections
|
UPDATE |
Permite el uso de UPDATE
|
USAGE |
Sinónimo de “no privileges” |
GRANT OPTION |
Permite dar permisos |
El permiso EXECUTE
no es operacional hasta
MySQL 5.0.3. CREATE VIEW
y SHOW
VIEW
se añadieron en MySQL 5.0.1. CREATE
USER
, CREATE ROUTINE
, y
ALTER ROUTINE
se añadieron en MySQL 5.0.3.
Para usar estos permisos al actualizar desde una versión
anterior de MySQL que no los tenga, debe actualizar primero
las tablas de permisos, como se describe en
Sección 2.10.2, “Aumentar la versión de las tablas de privilegios”.
El permiso REFERENCES
actualmente no se
usa.
USAGE
puede especificarse cuando quiere
crear un usuario sin permisos.
Use SHOW GRANTS
para determinar qué
permisos tiene la cuenta. Consulte
Sección 13.5.4.10, “Sintaxis de SHOW GRANTS
”.
Puede asignar permisos globales usando sintaxis ON
*.*
o permisos a nivel de base de datos usando la
sintaxis ON
. Si especifica
db_name
.*ON *
y tiene seleccionada una base de datos
por defecto, los permisos se dan en esa base de datos.
(Atención: Si especifica
ON *
y no ha
seleccionado una base de datos por defecto, los permisos dados
son globales.)
Los permisos FILE
,
PROCESS
, RELOAD
,
REPLICATION CLIENT
, REPLICATION
SLAVE
, SHOW DATABASES
,
SHUTDOWN
, y SUPER
son
permisos administrativos que sólo pueden darse globalmente
(usando sintaxis ON *.*
).
Otros permisos pueden darse globalmente o a niveles más específicos.
Los únicos valores priv_type
que puede
especificar para una tabla son SELECT
,
INSERT
, UPDATE
,
DELETE
, CREATE
,
DROP
, GRANT OPTION
,
INDEX
, y ALTER
.
Los únicos valores priv_type
que puede
especificar para una columna (cuando usa la cláusula
column_list
) son
SELECT
, INSERT
, y
UPDATE
.
Los únicos valores priv_type
que puede
especificar a nivel de rutina son ALTER
ROUTINE
, EXECUTE
, y
GRANT OPTION
. CREATE
ROUTINE
no es un permiso de nivel de rutina porque
debe tener este permiso para ser capaz de crear una rutina en
primer lugar.
Para los niveles global, base de datos, tabla y rutina,
GRANT ALL
asigna sólo los permisos que
existen en el nivel que está otorgándolos. Por ejemplo, si
usa GRANT ALL ON
, este es un
comando de nivel de base de datos, así que ninguno de los
permisos únicamente globales tales como
db_name
.*FILE
se otorgan.
MySQL le permite dar permisos incluso en objetos de bases de
datos que no existen. En tales casos, los permisos a dar deben
incluir el permiso CREATE
. Este
es el comportamiento diseñado, y se pretende
permitir al administrador de la base de datos perparar cuentas
de usuario y permisos para objetos de base de datos que se
crearán posteriormente.
MySQL no elimina automáticamente nigún permiso si borra una tabla o base de datos . Si borra un rutina, se quita cualquier permiso dado a nivel de rutina para la misma.
Nota: los carácters comodín
'_
' y '%
' se permiten al
especificar nombres de base de datos en comandos
GRANT
que otorgan permisos a nivel global o
de base de datos. Esto significa, por ejemplo, que si quiere
usar un carácter '_
' como parte de un
nombre de base de datos, debe especificarlo como
'\_
' en el comando GRANT
, para evitar que el usuario sea capaz de acceder a bases de
datos adicionales que coincidan con el patrón de los
comodines, por ejemplo GRANT ... ON `foo\_bar`.* TO
...
.
Para acomodar los permisos a los usuarios de equipos
arbitrários, MySQL soporta especificar el valor
user
con la forma
.
Si un valor user_name
@host_name
user_name
o
host_name
es legal como
identificador sin poner entre comillas, no necesita hacerlo.
Sin embargo, las comillas son necesarias para especificar una
cadena user_name
conteniendo
caracteres especiales (tales como '-
'), o
una cadena host_name
conteniendo
caracteres especiales o comodín (tales como
'%
'); por ejemplo,
'test-user'@'test-hostname'
. Entrecomille
el nombre de usuario y de equipo separadamente.
Puede especificar caracteres comodín en el nombre de equipo.
Por ejemplo,
se aplica a user_name
@'%.loc.gov'user_name
para
cualquier equipo en el dominio loc.gov
, y
se aplica a user_name
@'144.155.166.%'user_name
para
cualquier equipo en la clase subred clase C
144.155.166
.
La forma simple user_name
es
sinónimo de
.
user_name
@'%'
MySQL no soporta comodines en el nombre de usuario. Los
usuarios anónimos se definien insertando entradas con
User=''
en la tabla
mysql.user
o creando un usuario con un
nombre vacío con el comando GRANT
:
mysql> GRANT ALL ON test.* TO ''@'localhost' ...
Al especificar valores delimitados, use comillas simples para
delimitar los nombres de bases de datos, tabla, columna y de
rutina ('`
'). Para los nombres de equipo,
nombres de usuario, y contraseñas como cadenas, use
apóstrofes (''
').
Advertencia: Si permite
conectar con el servidor a usuarios anónimos, debe dar
permisos a todos los usuarios locales como
.
De otro modo, la cuenta de usuario anónimo para
user_name
@localhostlocalhost
en la tabla
mysql.user
(creada durante la instalación
de MySQL) se usa cuando los usuarioa con nombre intentan
loguear con el servidor MySQL desde la máquina local.
Puede determinar si esto se aplica a su sistema ejecutando la siguiente consulta, que lista cualquier usuario anónimo:
mysql> SELECT Host, User FROM mysql.user WHERE User='';
Si quiere borrar la cuenta anónima local para evitar el problema descrito, use estos comandos:
mysql> DELETE FROM mysql.user WHERE Host='localhost' AND User=''; mysql> FLUSH PRIVILEGES;
GRANT
soporta nombres de equipo de hasta 60
caracteres. Los nombres de bases de datos, tablas, columnas y
rutinas pueden tener hasta 64 caracteres. Los nombres de
usuario pueden tener hasta 16 caracteres. Los nombres de
usuario pueden tener hasta 16 caracteres. Estos
límites están harcodeados en el software MySQL y no pueden
cambiarse alterando las tablas de permisos .
Los permisos para una tabla o columna se forman de forma
aditiva como una OR
lógica de los permisos
en cada uno de los cuatro niveles de permisos. Por ejemplo, si
la tabla mysql.user
especifica que un
usuario tiene un permiso SELECT
global, el
permiso no puede denegarse mediante una entrada en el nivel de
base de datos, tabla o columna.
Los permisos de una columna pueden calcularse como sigue:
global privileges OR (database privileges AND host privileges) OR table privileges OR column privileges
En la mayoría de casos, puede dar derechoa a un usuario en sólo uno de los niveles de permisos, así que la vida normalmente no es tan complicada. Los detalles de este procedimiento de chequeo de permisos se presentan en Sección 5.6, “El sistema de privilegios de acceso de MySQL”.
Si otorga permisos para una combinación usuario/equipo que no
existe en la tabla mysql.user
se añade una
entrada que permite allí hasta que se borra con un comando
DELETE
. En otras palabras,
GRANT
puede crear entradas
user
pero REVOKE
no los
borra; debe hacerlo explícitamente usando DROP
USER
o DELETE
.
Si se crea un nuevo usuario o si tiene permisos globales para
otorgar permisos, la contraseña de usuario se cambia con la
contraseña especificada por la cláusula IDENTIFIED
BY
, si se da una. Si el usuario ya tiene una
contraseña, esta se reemplaza por la nueva.
Atención: Si crea un nuevo
usuario pero no especifica una cláusula IDENTIFIED
BY
, el usuario no tiene contraseña. Esto es muy
poco seguro. Desde MySQL 5.0.2, puede activar el modo SQL
NO_AUTO_CREATE_USER
para evitar que
GRANT
cree un nuevo usuario si lo hiciese
de otro modo, a no ser que IDENTIFIED BY
se
de para proporcionar la nueva contraseña de usuario.
Las contraseñas pueden ponerse con el comando SET
PASSWORD
. Consulte Sección 13.5.1.5, “Sintaxis de SET PASSWORD
”.
En la cláusula IDENTIFIED BY
, la
contraseña debe darse como el valor de contraseña literal.
No es necesario usar la función PASSWORD()
como lo es para el comando SET PASSWORD
.
Por ejemplo:
GRANT ... IDENTIFIED BY 'mypass';
Si no quiere enviar la contraseña en texto plano y conoce el
valor haseado que PASSWORD()
retornaría
para la contraseña, puede especificar el valor hasheado
precedido por la palabra clave PASSWORD
:
GRANT ... IDENTIFIED BY PASSWORD '*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4';
En un programa C , puede obtener el valor haseado usando la
función make_scrambled_password()
de la
API de C.
Si da permisos para una base de datos, se crea una entrada en
la tabla mysql.db
si es necesario. Si todos
los permisos para la base de datos se eliminan con
REVOKE
, esta entrada se borra.
Si un usuario no tiene permisos para una tabla, el nombre de
tabla no se muestra cuando el usuario pide una lista de talbas
(por ejemplo, con el comando SHOW TABLES
).
El permiso SHOW DATABASES
le permite a la
cuenta ver nombres de bases de datos realizando el comando
SHOW DATABASE
. Las cuentas que no tienen
este permiso sólo ven las bases de datos para las que tienen
algún permiso, y no pueden usar el comando para nada si el
servidor se arranca con la opción
--skip-show-database
.
La cláusula WITH GRANT OPTION
le da al
usuario la habilidad para dar a otros usuarios cualquier
permiso que tenga el usuario en el nivel de permiso
especificado. Debe tener cuidado de a quién da el permiso
GRANT OPTION
, ya que dos usuarios con
permisos distintos pueden ser capaces de juntar permisos!
No puede dar a otro usuario un permiso que no tenga usted
mismo; el permiso GRANT OPTION
le permite
asignar sólo los permisos que tenga usted.
Tenga en cuenta que cuando le da a un usuario el permiso
GRANT OPTION
a un nivel de permisos
particular, cualquier permiso que tenga el usuario (o que se
de en el futuro!) a este nivel también son otorgables por
este usuario. Suponga que le da a un usuario el permisos
INSERT
en una base de datos. Si otorga el
permiso SELECT
en la base de datos y
especifica WITH GRANT OPTION
, el usuario
puede quitar no sólo el permiso SELECT
sino también INSERT
. Si luego otorga el
permiso UPDATE
al usuario en la base de
datos, el usuario puede quitar INSERT
,
SELECT
, y UPDATE
.
No debe otorgar permisos ALTER
a un usuario
normal. Si lo hace, el usuario puede intentar engañar al
sistema de permisos renombrando tablas!
Las opciones MAX_QUERIES_PER_HOUR
,
count
MAX_UPDATES_PER_HOUR
, y
count
MAX_CONNECTIONS_PER_HOUR
limitan el número
de consultas, actualizaciones, y logueos que puede realizar un
usuario durante cualquier perído de una hora. Si
count
count
es 0 (por defecto), esto
significa que no hay limitación para ese usuario.
La MAX_USER_CONNECTIONS
opción,
implementada en MySQL 5.0.3, limita el máximo número de
conexiones simultáneas que la cuenta puede hacer. Si
count
count
es 0 (por defecto), la
max_user_connections
variable de sistema
determina el número de conexiones simultáneas para la
cuenta.
Nota: para especificar cualquiera de estas opciones de
limitación de recursos para un usuario existente sin afectar
a los permisos existentes, use GRANT USAGE ON *.* ...
WITH MAX_...
.
Consulte Sección 5.7.4, “Limitar recursos de cuentas”.
MySQL puede chequear atributos certificados X509 además que
la autenticación usual que se basa en el nombre de usuario y
contraseña. Para especificar opciones relacionadas con SSL
para la cuenta MySQL, use la cláusula
REQUIRE
del comando
GRANT
. (Para información de transfondo
sobre el uso de SSL con MySQL, consulte
Sección 5.7.7, “Usar conexiones seguras”.)
Hay distintas posibilidades para limitar tipos de conexión para una cuenta:
Si una cuenta no tiene requerimientos de SSL o X509, se permiten conexiones sin encriptar si la contraseña y nombre de usuario son válidos. Sin embargo, las conexiones no encriptadas pueden usarse en las opciones de cliente, si el cliente tiene los ficheros clave y de certificado apropiados.
La opción REQUIRE SSL
le dice al
servidor que permita sólo conexiones SSL encriptadas para
la cuenta. Tenga en cuenta que esta opción puede omitirse
si hay algunos registros de control de acceso que permitan
conexiones no SSL.
mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' -> IDENTIFIED BY 'goodsecret' REQUIRE SSL;
REQUIRE X509
significa que el cliente
debe tener un certificado válido pero que el certificador
exacto y el asunto no importan. El único requerimiento
que debe ser posible de verificar es la firma con uno de
las AC certificadas.
mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' -> IDENTIFIED BY 'goodsecret' REQUIRE X509;
REQUIRE ISSUER
'
crea una
restricción de intentos de conexión en que el cliente
debe presentar un certificado X509 válido presentado por
la AC issuer
'issuer
. Si el cliente
presenta un certificado válido pero de otra AC, el
servidor rehúsa la conexión. El uso de certificados X509
siempre implica encripción, por lo que la opción
SSL
no es necesaria.
mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' -> IDENTIFIED BY 'goodsecret' -> REQUIRE ISSUER '/C=FI/ST=Some-State/L=Helsinki/ O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com';
Tenga en cuenta que el valor ISSUER
debe entrarse como una cadena única.
REQUIRE SUBJECT
'
crea la
restricción en los intentos de conexión de que el
cliente debe presentar un certificado X509 válido con el
asunto subject
'subject
. Si el cliente
presenta un certificado válido pero con un asunto
distinto, el servidor rehúsa la conexión.
mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' -> IDENTIFIED BY 'goodsecret' -> REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/ O=MySQL demo client certificate/ CN=Tonu Samuel/Email=tonu@example.com';
Tenga en cuenta que el valor SUBJECT
debe entrarse como una única cadena.
REQUIRE CIPHER
'
se necesita
para asegurar que se usan cifradores suficientemente
fuertes y longitudes de claves acordes. SSL por sí mismo
puede ser débil si se usan algoritmos antiguos con claves
de encriptación cortas. Con esta opción, puede
especificar el método de cifrado exacto para permitir una
conexión.
cipher
'
mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' -> IDENTIFIED BY 'goodsecret' -> REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';
Las opciones SUBJECT
,
ISSUER
, y CIPHER
pueden
combinarse en la cláusula REQUIRE
así:
mysql> GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' -> IDENTIFIED BY 'goodsecret' -> REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/ O=MySQL demo client certificate/ CN=Tonu Samuel/Email=tonu@example.com' -> AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/ O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com' -> AND CIPHER 'EDH-RSA-DES-CBC3-SHA';
Tenga en cuenta que los valores SUBJECT
y
ISSUER
deben entrarse como una única
cadena.
En MySQL 5.0, la palabra clave AND
es
opcional entre las opciones REQUIRE
.
El orden de las opciones no importa, pero no puede especificarse ninguna opción dos veces.
Cuando mysqld arranca, todos los permisos se leen en memoria. Para más detalles, consulte Sección 5.6.7, “Cuándo tienen efecto los camios de privilegios”.
Tenga en cuenta que si usa permisos de tablas o de columnas para un usuario, el servidor examina los permisos de tablas y usuarios para todos los usuarios y esto ralentiza MySQL ligeramente. De forma similar, si limita el número de consultas, actualizaciones o conexiones para cualquier usuario, el servidor debe monitorizar estos valores.
Las mayores diferencias entre las versiones de
GRANT
de MySQL y SQL estándar son:
En MySQL, los permisos se asocian con una combinación de nombre de usuario/equipo y no sólo con el usuario.
SQL estándar no tienen permisos globales o a nivel de base de datos, ni soporta todos los tipos de permisos que soporta MySQL .
MySQL no soporta los permisos de SQL estándar
TRIGGER
o UNDER
.
Los permisos de SQL estándar se estructuran de forma
jerárquica. Si borra un usuario, todos los permisos que
tuviera el usuario se eliminan. Esto es cierto a partir de
MySQL 5.0.2 y si usa DROP USER
. Antes
de 5.0.2, los permisos otorgados no se eliminaban
automáticamente; debía hacerlo a mano. Consulte
Sección 13.5.1.2, “Sintaxis de DROP USER
”.
En SQL estándar, cuando borra una tabla, todos los
permisos para la tabla se eliminan. Con SQL estándar,
cuando quita un permiso, todos los permisos otorgados
basados en ese permiso también se eliminaban. En MySQL,
los permisos sólo pueden borrarse con comandos
REVOKE
explícitos o manipulando las
tablas de permisos de MySQL.
En MySQL, es posible tener el permiso
INSERT
sólo para algunas de las
columnas en la tabla. En este caso, todavía puede
ejecutar comandos INSERT
en la tabla
mientras omita esas columnas para las que no tiene el
permiso INSERT
. Las columnas omitidas
obtienen su valor por defecto implícito si no está
activado el modo SQL estricto. En modo estricto, el
comando se rehúsa si algunas de las columnas omitidas no
tienen valor por defecto.
Sección 5.3.2, “El modo SQL del servidor” discute acerca del modo
estricto. Sección 13.1.5, “Sintaxis de CREATE TABLE
” disctue acerca de
los valores por defecto implícitos.
Las columnas para las que no tiene el permiso
INSERT
se ponen a su valor por defecto.
SQL estándar requiere que tenga el permiso
INSERT
en todas las columnas.
En MySQL, si tiene el permiso INSERT sólo en alguna de las columnas de la tabla, puede ejecutar comandos INSERT — mientras omita las columnas para las que no tiene el permiso de su comando INSERT; tales columnas obtendrán su valor por defecto. En modo estricto (cuando sql_mode="traditional"), si alguna de las columnas omitidas no tiene valor por defecto, el comando INSERT se rehúsa.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.