Definición de los datos
Introducción
El lenguaje de definición de los datos se basa en tres sentencias: CREATE, ALTER y DROP, que se aplican a cada objeto de la base de datos. Cada objeto se puede corresponder con un objeto físico, es decir, un archivo en los sistemas de archivos, o a un objeto lógico, es decir, una definición almacenada en el catálogo de la base de datos.
La ejecución de estas sentencias implica necesariamente un bloqueo exclusivo de los objetos afectados. Con este bloqueo exclusivo, no se puede atender ningún otro bloqueo en modo lectura o escritura. Esto no supone ningún problema durante la creación de un objeto, porque ninguna sesión actual lo puede haber reclamado, pero durante la eliminación de un objeto hay que esperar a que todos los bloqueos existentes se liberen. En lo que respecta a una base de datos, por ejemplo, no debe haber sesiones conectadas a esta base de datos.
El impacto más importante se produce durante la modificación de un objeto porque el bloqueo permanece durante todo el tiempo de ejecución del comando y, por lo tanto, esto puede tener un impacto en la ejecución de consultas concurrentes.
En consecuencia, las sentencias de definición de los datos se deben ejecutar con precaución, eligiendo si es posible una ventana de tiempo oportuna.
Los espacios de tablas
Un espacio de tablas es un directorio de un sistema de archivos, en el que PostgreSQL escribe los archivos de las tablas y de los índices. Por defecto, PostgreSQL dispone de un espacio de tablas ubicado en el directorio del grupo de bases de datos. Es posible crear otros espacios de tablas, que permiten al administrador seleccionar de esta manera la ubicación del almacenamiento de una tabla o de un índice.
Hay varios motivos que pueden hacer que un administrador cree un espacio de tablas:
-
La partición ya no dispone de suficiente espacio libre. En este caso, los espacios de tablas permiten utilizar varios discos duros diferentes para un mismo grupo de base de datos, sin utilizar sistemas de volúmenes lógicos, como LVM en los sistemas GNU/Linux.
-
La utilización de las tablas y de los índices provoca una saturación de las escrituras y lecturas del subsistema de disco en el que se ubica el espacio de tablas por defecto. Incluso en los sistemas de alto rendimiento, el escalado de una aplicación puede hacer que el administrador cree otros espacios de tablas en los subsistemas de discos diferentes. De esta manera, las escrituras y lecturas de archivos de tablas e índices se reparten en varios soportes físicos, mejorando el rendimiento.
Por lo tanto, un espacio de tablas es una herramienta que se puede utilizar por el administrador del servidor de bases...
Las bases de datos
En una instancia de PostgreSQL, una base de datos es un contenedor. Contiene los esquemas, las tablas, los índices y todos los objetos útiles para una aplicación. También recibe las conexiones desde las aplicaciones cliente. En efecto, cuando se abre una conexión en una base de datos particular, no es posible utilizar directamente los objetos creados en otras bases de datos.
Por lo tanto, es importante repartir correctamente los objetos y los datos de las aplicaciones en las bases de datos, principalmente utilizando la noción de esquema. La creación de una base de datos se puede realizar con la sentencia CREATE DATABASE o con el comando del sistema operativo createdb.
Algunos argumentos permiten personalizar la creación de una base de datos:
-
Para crear una base de datos, es necesario ser superusuario o tener el permiso CREATEDB. Por el contrario, es posible transmitir la pertenencia a un usuario que no tiene permisos con la opción OWNER. La opción del comando createdb es -O o --owner.
-
La base de datos template1 sirve de modelo por defecto para la creación de otra base de datos. Para cada base de datos creada con este modelo, se hace una copia de template1, para que todos los objetos creados en template1 se dupliquen en la nueva base. La base template0 funciona de la misma manera, pero no es posible crear objetos en esta base-modelo: template0 es una base de datos virgen. Es posible seleccionar la base de datos que sirve de modelo con la opción TEMPLATE y, por supuesto, es posible seleccionar cualquier base de datos modelo existente. La opción del comando createdb es -T o --template.
-
Un argumento importante durante la creación de una base de datos es la elección del juego de caracteres. Determina la manera...
Los esquemas
Los esquemas, también llamados espacios de nombres, existen implícitamente en todas las bases de datos. Se trata de una noción puramente lógica, que permite agrupar por nombre los objetos como las tablas, las vistas o las funciones, que definen de esta manera una ruta de acceso.
De esta manera, en una misma base de datos hay varios objetos que pueden tener el mismo nombre, pero ser físicamente distintos. El nombre del esquema utiliza como prefijo el nombre del objeto. En consecuencia, la distinción entre los objetos es clara.
Se puede hacer una analogía con la noción de paquete o namespace en diferentes lenguajes de programación. Objetos con nombres idénticos (atributos, métodos...) pero con una implementación diferente se pueden distinguir por el nombre del paquete. En PostgreSQL, la noción es idéntica, considerando el hecho de que una clase se corresponde con una tabla y la implementación, con los datos. Por lo tanto, el paquete se corresponde con un esquema. A pesar de esta analogía, observe una diferencia importante: solo existe un nivel de profundidad con los esquemas. En PostgreSQL, no es posible crear esquemas en un esquema.
Inicialmente existen varios esquemas en una base de datos:
-
El esquema pg_catalog contiene las tablas y vistas de sistema, que permiten a PostgreSQL almacenar la información relativa a su funcionamiento.
-
El esquema...
Las tablas
Una tabla es el elemento básico de un servidor de bases de datos. En ella es donde se almacenan los datos, y la organización de las tablas determina la calidad de la base de datos.
La elección de los tipos de datos y los enlaces entre las tablas forman parte de la etapa de diseño de la base de datos para que tenga buen rendimiento y sea duradera.
La sentencia CREATE TABLE permite poner en marcha las elecciones de este diseño.
La sinopsis mínima de este comando es la siguiente:
CREATE [ TEMP | UNLOGGED ] TABLE [ IF NOT EXISTS ] nombretabla ( [
{ nombrecol tipo [ COLLATE collation ] [ restriccioncolumna[...] ]
| restricciontabla
| LIKE source_table [ like_option ... ]
} [,...] ] )
[ INHERITS ( parent_table [, ... ] ) ]
[ WITH ( storage_parameter [= value] [, ... ] )
| WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace_name ]
Previo a la definición de los atributos de una tabla, se puede indicar un determinado número de características adicionales para modificar el comportamiento de una tabla en la base de datos.
En primer lugar, los modificadores TEMP y UNLOGGED permiten cambiar la naturaleza de una tabla:
-
Una tabla temporal creada con el modificador TEMP solo es visible en el contexto de la sesión actual, es decir, ninguna otra sesión concurrente tiene acceso a esta tabla y esta deja de existir cuando termina la sesión. La sentencia ON COMMIT modifica la visibilidad de la tabla temporal a nivel de la transacción. Por defecto, los registros se conservan hasta el final de la sesión (PRESERVE ROWS), pero es posible eliminarlos (DELETE ROWS) o eliminar la tabla temporal al final de la transacción (DROP). Los índices asociados a esta tabla también son temporales y, por lo tanto, se elimina en el mismo momento que la tabla. Una tabla temporal puede tener el mismo nombre que una tabla permanente. En este caso, será la única visible mientras dure la sesión.
-
Una tabla creada con el modificador UNLOGGED no ve sus datos guardados en los archivos de traza de transacciones. Este mecanismo que implementa la durabilidad de datos puede provocar que haya datos que desaparezcan en casos de parada accidental de la instancia. En contrapartida...
Las vistas
Una vista es el equivalente de una consulta SELECT, pero almacenada en forma de una relación equivalente a una tabla, aunque en modo solo lectura. Los datos mostrados por una vista no son modificables y la consulta SELECT subyacente se lanza en cada llamada a la vista. El interés de una vista es presentar los datos de una determinada manera y estar siempre disponible.
La sentencia CREATE VIEW permite crear una vista basándose en una consulta SELECT, como en la siguiente sinopsis:
CREATE [ OR REPLACE ] [ TEMP ] VIEW nombre [ ( columna, ... ) ]
WITH ( nombreopción = valor] [, ... ] )
AS consulta
WITH [ CASCADED | LOCAL ] CHECK OPTION;
Por defecto, el nombre de las columnas de la vista se corresponden con el nombre de las columnas devueltas por la consulta SELECT. Es posible modificar estos nombres de columna indicándolos entre paréntesis, después del nombre de la tabla.
Además, es posible sustituir una vista existente, añadiendo las palabras clave OR REPLACE después de CREATE, con la condición de que las columnas de la vista sean identicas en número y tipo.
La sentencia TEMP modifica el alcance de la vista, haciéndola accesible únicamente durante la sesión actual y solo durante el tiempo de la sesión. Por lo tanto, la vista se elimina al final de la sesión. Cuando una vista temporal tiene el mismo nombre que un objeto existente, es prioritaria sobre este objeto durante la sesión.
Es posible actualizar los datos presentados por una vista con algunas condiciones concretas. La sentencia WITH CHECK OPTION permite verificar si las modificaciones añadidas a los datos se corresponden con las cláusulas de la vista, es...
El sistema de reglas
En PostgreSQL existe un sistema de reescritura de consultas, llamado reglas de reescritura, que permite modificar en profundidad la interpretación de las sentencias SQL. El comportamiento es muy cercano al de los triggers, pero, mientras que un trigger permite acciones antes o después de una consulta, una regla permite devolver una acción para realizarla en su lugar.
La sinopsis de la sentencia de creación de una regla es la siguiente:
CREATE [ OR REPLACE ] RULE nombre AS ON evento
TO table [ WHERE condición ]
DO [ ALSO | INSTEAD ] { NOTHING | comando |
( comando; comando ... ) }
Las palabras clave OR REPLACE permiten sustituir una regla existente, por lo tanto con el mismo nombre.
El evento debe ser una de las cuatro sentencias de manipulación de los datos (SELECT, UPDATE, INSERT y DELETE).
La condición permite filtrar la reescritura, en función de los valores del registro seleccionado, con la palabra clave OLD que designa al registro.
La palabra clave ALSO indica que se realiza la consulta que desencadena la reescritura, mientras que la palabra clave INSTEAD indica que esta consulta no se ejecutará más.
Para terminar, se indica la acción que se ha de realizar o de lo contrario se indica la palabra clave NOTHING. Es posible realizar varias acciones indicándolas entre paréntesis.
1. Eliminación...
La herencia
PostgreSQL propone un sistema de herencia para las tablas, lo que permite a una tabla hija heredar las columnas de la tabla madre y, además, tener sus propias columnas. Cuando se inserta una tupla en la tabla hija, los datos también son visibles desde la tabla madre. Solo se almacenan físicamente en esta tabla las columnas propias de la tabla hija.
Por ejemplo, la tabla prestaciones de la base de datos clientes permite almacenar información genérica de las prestaciones. Creando una tabla formaciones, que hereda de la tabla prestaciones, es posible especializar esta tabla, añadiendo campos, como en el siguiente ejemplo:
CREATE TABLE formaciones (
num_becarios int,
plandeestudios varchar(25),
tipo varchar(5) check ( tipo in ('intra','inter') ))
INHERITS (prestaciones);
La descripción de la tabla por el comando \d muestra que las columnas de la tabla madre forman efectivamente parte de esta nueva tabla:
clientes=# \d formaciones
Tabla "public.formaciones"
Columna | Tipo | Modificadores
——————————————————-+——————————————————————————+———————-...
Administración de datos externos
PostgreSQL dispone de mecanismos que permiten acceder a los datos situados en el exterior de una instancia. La implementación responde al estándar SQL/MED.
Esta implementación permite utilizar un componente externo que define los métodos útiles para conectarse a un servicio, como un servidor de base de datos, o abrir un recurso, como un archivo CSV. Estos componentes no se proporcionan con PostgreSQL, excepto el conector hacia PostgreSQL, sino por los proyectos externos. Estas implementaciones se llaman «wrappers».
Si bien este mecanismo permite utilizar datos externos en modo lectura y escritura, no todos los componentes específicos implementan la escritura de datos.
Una vez que se instala el componente externo, es posible definir una conexión hacia un servicio externo y establecer una correspondencia entre un usuario local de la instancia PostgreSQL con un usuario autorizado para conectarse al servicio externo.
Para terminar, una tabla extranjera se crea para hacer la correspondencia entre una entidad del servicio externo y una relación local a la instancia PostgreSQL.
1. Wrappers
a. Lista de wrappers disponibles
Los wrappers disponibles para la instalación no se entregan con PostgreSQL, excepto los wrappers postgres_fdw y file_fdw. Según las necesidades, se han desarrollado diferentes wrappers y generalmente están disponibles en forma de código fuente, como software libre.
La wiki de PostgreSQL hace referencia a los proyectos existentes en la siguiente dirección: https://wiki.postgresql.org/wiki/Foreign_data_wrappers y el almacén pgxn integra algunos: http://pgxn.org/tag/fdw/
La siguiente tabla resume las características de los principales wrappers:
nombre |
lectura/escritura |
pxgn |
oracle_fdw |
Sí |
Sí |
mysql_fdw |
Sí |
Sí |
tds_fdw (MS-SQL Server, Sybase) |
No |
Sí |
sqlite_fdw |
No |
No |
redis_fdw |
No |
Sí |
couchdb_fdw |
No |
Sí |
ldap_fdw |
No |
Sí |
hadoop_fdw |
No |
No |
b. Creación de un wrapper
Este comando hace que el conector externo esté disponible en la base de datos actual. Por defecto, no hay conector instalado. Por lo tanto, es necesario instalar el wrapper como extensión con la sentencia SQL CREATE EXTENSION que, en la mayor...
Los índices
Un índice es una buena herramienta para mejorar el rendimiento de la base de datos. La analogía con un libro permite entender el papel que juega un índice en una base de datos. Sin índices, cuando un lector busca una información, debe leer el libro hasta encontrar lo que busca. Según el tamaño del libro y el lugar en el que se sitúa la información, inicio o fin, la búsqueda puede ser larga. En la mayor parte de los libros técnicos, el editor incorpora un índice de algunas páginas, que contiene las palabras clave consideradas susceptibles de ser buscadas para que resulte más fácil encontrar el concepto. El lector no tiene más que buscar en el índice e ir a la página indicada.
Los servidores de bases de datos almacenan los datos en las tablas y deben leer las tablas cuando un usuario busca un dato. El método más sencillo es recorrer secuencialmente una tabla hasta encontrar el dato buscado. Este método funciona bien mientras la tabla tenga un volumen que haga que los tiempos para recorrerla sean correctos. Más allá de un límite que depende del tipo de datos utilizados, del número de columnas de la tabla y del número de tuplas, el recorrido secuencial de la tabla es demasiado largo para obtener un tiempo de respuesta razonable. Se hace necesario crear uno o varios índices, en función de las búsquedas realizadas sobre la tabla.
La analogía con el libro termina aquí. En efecto, un libro tiene un contenido estático, al contrario de lo que sucede con una base de datos, cuyo contenido evoluciona con el tiempo. Esto significa que los índices se deben actualizar al mismo tiempo que la tabla. Cuantos más índices asociados tenga una tabla, más tiempo lleva la actualización durante las operaciones de inserción, actualización o eliminación de los datos. El tiempo susceptible de ganarse en la lectura se pierde durante la escritura.
Por lo tanto, la creación de un índice es un delicado equilibrio entre la mejora deseada en la lectura y la bajada de rendimiento durante la escritura. El sencillo hecho de crear muchos índices sobre una misma tabla puede penalizar.
Además, un índice ocupa un volumen no despreciable en el sistema de archivos...
Secuencias y atributos de identidad
Una secuencia es un tipo de objeto un poco particular. Se corresponde con un contador que se puede manipular con algunas funciones; principalmente la función nextval(), que permite incrementar el valor del contador y recuperarlo. Esto permite por ejemplo obtener una especie de incremento automático de una columna. Además, es posible compartir una misma secuencia entre varias tablas, creando de esta manera un identificador único intertablas.
El atributo de identidad aparece con la versión 10 de PostgreSQL. Se trata de una funcionalidad muy cercana a las secuencias, pero implementando en PostgreSQL lo que se define en la norma SQL ISO.
Los tipos de datos SERIAL y BIGSERIAL crean automáticamente una secuencia y utilizan la función nextval() en la expresión del valor por defecto de la columna.
En una tabla como la tabla prestaciones, la clave primaria se define como un entero. Es posible utilizar una secuencia para alimentarla automáticamente. El siguiente ejemplo muestra el uso más sencillo:
CREATE TABLE prestaciones ( prest_id serial primary key ,
[ ... ]
);
que es equivalente a:
CREATE SEQUENCE prest_id_seq;
CREATE TABLE prestaciones (
prest_id integer default nextval( prest_id_seq )
primary key ,
[ ... ]
);
De esta manera...
Tipos de datos
Existe muchos tipos de datos en PostgreSQL, que se corresponden con la mayor parte de los tipos de datos de la norma SQL.
1. Tipo de datos numéricos
-
smallint, int2: entero con signo sobre 2 bytes.
-
integer, int, int4: entero con signo sobre 4 bytes.
-
bigint, int8: entero con signo sobre 8 bytes.
-
serial, serial4: entero sobre 4 bytes con incremento automático. Es un entero asociado a una secuencia.
-
bigserial, serial8: entero sobre 8 bytes con incremento automático. Es un entero asociado a una secuencia.
-
real, float4: número en coma flotante de precisión simple sobre 4 bytes con 6 decimales.
-
double precision, float8: número en coma flotante de precisión doble sobre 8 bytes con 15 decimales.
-
numeric [ (p, s) ], decimal [ (p, s) ]: número exacto de precisión indicada. Este tipo es particularmente recomendable para los valores monetarios o todos los tipos numéricos donde la parte flotante no deba variar. Las indicaciones se corresponden con el número total de dígitos (p) después de la parte decimal (s).
No existen tipos u opciones que definan un tipo no firmado. Por lo tanto, los rangos de valores se definen centrados en el cero.
2. Tipo de datos «caracteres»
-
char [ (n) ], character [ (n) ]: sucesión de caracteres de longitud fija.
-
character varying [ (n) ], varchar [ (n) ]: sucesión de caracteres de longitud variable limitada.
-
text: cadena...
Dominios
Un dominio de datos es una extensión de un tipo de datos asociado a las restricciones y verificaciones que solo permiten definir una vez este conjunto y reutilizarlo en varias tablas. Por ejemplo, un campo direccion_correo electronico se puede definir como dominio y reutilizar en toda la aplicación.
1. Creación de un dominio
La sinopsis del comando es la siguiente:
CREATE DOMAIN nombre [AS] tipodato
[ DEFAULT expresión ]
[ [ CONSTRAINT restricción ]
{ NOT NULL | NULL | CHECK (expresión) } ]
La creación de un dominio de datos es muy parecida a la definición de un atributo. Las diferentes opciones son las mismas.
2. Modificación de un dominio
La modificación de un dominio es similar a la modificación de un atributo, utilizando el comando ALTER DOMAIN. La diferencia es que la mayor parte de las modificaciones no se aplican a los datos de las tablas que utilizan el dominio. La sinopsis del comando es la siguiente:
ALTER DOMAIN nombre { SET DEFAULT expresión | DROP DEFAULT }
ALTER DOMAIN nombre { SET | DROP } NOT NULL
ALTER DOMAIN nombre ADD restricción [ NOT VALID ]
ALTER DOMAIN nombre DROP CONSTRAINT [ IF EXISTS ] restricción
[ RESTRICT | CASCADE ]
ALTER DOMAIN nombre RENAME CONSTRAINT restricción TO restricción2 ...
Búsqueda textual
La búsqueda textual en PostgreSQL es un conjunto de funciones que permiten el análisis y la indexación de textos a partir de las raíces de las palabras de este texto, proporcionando los elementos de ordenación en función de la proximidad del resultado con la búsqueda.
Al contrario de lo que sucedía con las expresiones normales o con el operador LIKE, este tipo de búsqueda permite la utilización de índices que mejoran el rendimiento y facilita la búsqueda de las raíces de palabras en función de un idioma, lo que posibilita efectuar búsquedas sobre palabras similares.
Las palabras se convierten en raíces o lexemas, que permiten la cercanía de palabras similares con la misma raíz.
Una búsqueda en un texto es la correspondencia entre un documento de tipo tsvector y una consulta de tipo tsquery. Esta correspondencia es verdadera o falsa y se determina por el operador @@.
Búsqueda en una tabla
La búsqueda en una o varias columnas de tipo text en una tabla pasa por la conversión a un documento tsvector, lo que permite asociarlo a una búsqueda tsquery. Por ejemplo, la siguiente consulta permite buscar la palabra clave ’Linux’ en el campo plandeestudios de la tabla formaciones:
SELECT * FROM formaciones WHERE to_tsvector(plandeestudios) @@
to_tsquery( 'Linux');
Para mejorar...
Extensiones
Las extensiones permiten añadir funcionalidades a PostgreSQL.
Una extensión es un conjunto coherente de funciones, tipos de datos, operadores o cualquier otro objeto útil, que ofrece una nueva funcionalidad a PostgreSQL. Una extensión se puede proporcionar por PostgreSQL o cualquier otro proveedor.
Estas extensiones pueden facilitar nuevos tipos de datos, como ltree o prefix, así como herramientas de administración, como pg_stat_statement o pg_buffercache.
Cuando se instala PostgreSQL mediante un sistema de paquetes, como en las distribuciones GNU/Linux Debian, Ubuntu, Red Hat o CentOS, un paquete específico contiene las extensiones proporcionadas por PostgreSQL: postgresql-contrib-10 para Debian y Ubuntu o postgresql10-contrib para Red Hat y CentOS.
Las extensiones no proporcionadas por PostgreSQL se instalan por el sistema de paquetes. Entonces, cada extensión es el objeto de un paquete específico; por ejemplo, postgresql-10-ip4r para Debian y Ubuntu o ip4r10 para Red Hat o CentOS.
Estos paquetes hacen referencia a una versión principal específica de PostgreSQL. Por una parte, porque la mayor parte de ellas se escriben en lenguaje C y, por lo tanto, se deben compilar en función de la versión elegida y, por otra parte, porque los archivos se deben instalar en la arborescencia de la versión principal de PostgreSQL.
Cuando se instalan los archivos que contienen el código de la extensión, esta extensión no está disponible inmediatamente. Falta crear los objetos en la base de datos deseada para permitir su utilización, por ejemplo en la creación de una tabla para un tipo de datos o en una consulta SELECT para una función.
1. Creación de una extensión
La sentencia CREATE EXTENSION permite esta disposición:
CREATE EXTENSION [ IF NOT EXISTS ] extensión
[ WITH ] [ SCHEMA nombresquema ]
[ VERSION versión ] [ FROM antiguaversión ]
[ CASCADE ]
Por defecto, la última versión de la extensión se instala en el esquema actual. Cuando se indica un esquema, se debe crear con anterioridad.
Las opciones VERSION y FROM permiten seleccionar una versión específica de la extensión.
Es posible que una extensión necesite otra extensión. Para facilitar...
Operadores y funciones
1. Operadores
Las listas que se presentan a continuación resumen los operadores principales disponibles en PostgreSQL.
a. Operadores de comparación
Cuando uno de los operandos comparados es NULL, entonces la comparación es NULL, salvo cuando el operador es IS DISTINCT FROM, siendo NULL la ausencia de valor.
-
<: devuelve true si el operando de la izquierda es más pequeño que el operando de la derecha.
-
>: devuelve true si el operando de la izquierda es más grande que el operando de la derecha.
-
<=: devuelve true si el operando de la izquierda es más pequeño o igual que el operando de la derecha.
-
>=: devuelve true si el operando de la izquierda es más grande o igual que el operando de la derecha.
-
=: devuelve true si los dos operandos son equivalentes.
-
<> o !=: devuelve true si los dos operandos no son equivalentes.
-
IS [ NOT ] DISTINCT FROM: devuelve true (o false) si los operandos son distintos el uno del otro, incluso si uno de los operandos es NULL.
-
IS [ NOT ] NULL: devuelve true (o false) si el operando es NULL.
Los siguientes operadores funcionan con tipos de datos compuestos, como las tablas, los rangos de valores o los tipos de datos JSON:
-
@>: devuelve true si el operando de la izquierda contiene al operando de la derecha.
-
<@: devuelve true si el operando de la izquierda está contenido por el operando de la derecha.
-
&&: devuelve true si los dos operandos se solapan.
Los siguientes operadores funcionan con rangos de valores:
-
>>: devuelve true si el operando de la izquierda está a la izquierda del operando de la derecha.
-
<<: devuelve true si el operando de la izquierda está a la derecha del operando de la derecha.
-
&>: devuelve true si el operando de la izquierda no se extiende a la derecha del operando de la derecha.
-
&<: devuelve true si el operando de la izquierda no se extiende a la izquierda del operando de la derecha.
-
-|-: devuelve true si el operando de la izquierda es adyacente al operando de la derecha.
Los siguientes operadores funcionan con los tipos de datos JSON y JSONB:
-
>>: devuelve true si el operando de la izquierda está a la izquierda del operando de la derecha.
-
<<: devuelve true si el operando de la izquierda está a la derecha del operando de la derecha.
Búsqueda de motivos
-
~, ~*: devuelve true si el operando de la izquierda se corresponde...
Manipulación de los datos
1. Inserción de datos
Existen dos métodos para alimentar las tablas con datos. El primero utiliza la sentencia INSERT, como en la norma SQL, y el segundo la sentencia COPY, principalmente para los casos de volúmenes de datos importantes durante la inserción.
a. La sentencia INSERT ... INTO
La sentencia INSERT respeta la notación de la norma SQL aportando algunas modificaciones.
La sinopsis de la sentencia INSERT es la siguiente:
[ WITH [ RECURSIVE ] consulta_cte [, ...] ]
INSERT INTO tabla
[ ( columna [, ...] ) ]
{
DEFAULT VALUES |
VALUES ( { expresión | DEFAULT } [, ...] ) |
consulta
}
[ ON CONFLICT [ ON CONSTRAINT restricción ]
DO NOTHING | DO UPDATE SET { columna = expresión } [, ...]
[ WHERE condición ] ]
[ RETURNING * | expr ]
Según el nombre de la tabla, la lista de las columnas permite indicar aquellas que se utilizarán. Cuando todas las columnas de la tabla se usan, esta lista no es obligatoria.
Para cada columna, el valor se expresa con su valor literal o con una expresión, respetando la sentencia de las columnas indicadas en la primera parte del comando.
El siguiente ejemplo muestra una inserción simple:
INSERT INTO clientes (cl_nombre, cl_direccion) VALUES ('S.T.E.R.E.G',
'Islas Pitiusas 2, 25290 Las Rozas');
En este caso, las columnas que no se utilizan tomarán el valor por defecto identificado en la definición de la tabla.
También es posible no utilizar los nombres de las columnas, como en el siguiente ejemplo:
INSERT INTO prestaciones VALUES ( 1 , 'nombre' ,
, '' , '13/06/2006', '12/06/2006', true ,'');
En este caso, se expresan los valores de todas las columnas. Entonces es posible indicar la palabra clave DEFAULT para utilizar el valor por defecto identificado en la definición de la tabla.
Es posible la utilización de subconsultas CTE, como en el caso de una consulta SELECT, y estas consultas se utilizan...