Planeta PostgreSQL-es

13 junio 2013

Samuel Zarza Fernandez

Comparar y actualizar esquemas de PostgreSQL



"1f y0u c4n r34d 7h15, y0u r34||y n33d 70 637 41d."

Al pasar a producción nuevas versiones de software empresarial necesitamos automatizar la "actualización" del sistema con el objeto de que sea repetible y pueda realizarse lo más rápidamente posible y sin errores. Uno de los elementos críticos es el esquema de nuestra base de datos sobre el cual, en la mayor parte de los casos, descansa la estructura vertebral de nuestro sistema.

Si la comparación y obtención de diferencias (comparison/diffing) entre el esquema antiguo y el nuevo es una tarea tediosa que está sujeta a numerosos errores, la generación de un script SQL de actualización es aún más compleja, ya que requiere un tratamiento inteligente y ordenado de dichas diferencias.

Para ayudarnos en esta tarea con PostgreSQL, me encontré una excelente herramienta: Another PostgreSQL Diff Tool (apgdiff). Agpdiff es una herramienta gratuita de comparación y obtención de diferencias de esquemas de bases de datos (database schema diff tool) específica para PostgreSQL. La he probado y he de decir que quedé realmente impresionado. Tan sólo tuve que añadir las lógicas modificaciones al script de actualización generado relacionadas con los datos (actualización de filas con valores NULL en campos que pasan a ser NOT NULL, etc...).

En el sitio de la herramienta viene información suficiente sobre su funcionamiento y cómo usarlo. Sólo añadir, como recomendación, la utilización de la opción --add-transaction que nos permitirá probarlo con comodidad y corregir los errores.

Una herramienta imprescindible si usas PostgreSQL.

Referencias y más información:

por Samuel Zarza Fernández (noreply@blogger.com) el 13 junio 2013 11:00

02 abril 2013

Rafael Martinez

Grave problema de seguridad

postgres-logo

Las versiones actuales de PostgreSQL tienen un grave problema de seguridad que será arreglado en las próximas versiones del producto. Las nuevas versiones serán lanzadas y estarán disponible el jueves 4 de abril 2013.

El grupo central (core team) de desarrolladores del proyecto PostgreSQL ha decidido también tomar medidas adicionales y extraordinarias para proteger los datos de los sistemas postgreSQL vulnerables.

leer más

por rafaelma el 02 abril 2013 09:03

Cuentas de usuarios para acceder a PostgreSQL-es

anuncio

Hace unos dias anunciamos que habiamos cambiado el proceso de registrar una cuenta de usuario en PostgreSQL-es para evitar el creciente problema de contenidos basura en la web.

Hemos cerrado el acceso automático despues de crear cuentas. Ahora un administrador debe de aprobar la cuenta creada antes de que el usuario pueda crear contenidos.

leer más

por rafaelma el 02 abril 2013 08:16

27 marzo 2013

Rafael Martinez

Problemas con contenidos basura en PostgreSQL-es

anuncio

Por la presente os informamos que hemos cambiado el proceso de registro para abrir una cuenta en PostgreSQL-es.

A partir de hoy, el administrador de la web tendrá que aprobar a los usuarios que se registren en PostgreSQL-es antes de que estos puedan crear contenidos. Con esta medida esperamos poder parar algunas de las cuentas que se crean solo para crear contenidos basura.

leer más

por rafaelma el 27 marzo 2013 12:24

08 febrero 2013

Rafael Martinez

Nuevas versiones de PostgreSQL disponibles

postgres-logo

El proyecto PostgreSQL ha lanzado nuevas versiones menores de todas las series activas de PostgreSQL. Esta actualización arregla entre otras cosas un problema de seguridad de clase D (denegación de servicio una vez conectados con un usuario/clave validos).

Las nuevas versiones disponibles son 9.2.3, 9.1.8, 9.0.12, 8.4.16 y 8.3.23.

Es importante recordar que la versión 8.3.23 será la última versión de la serie 8.3. Todos los usuarios que estén usando esta serie, deberian de actualizar a una versión soportada lo antes posible.

Anuncio oficial de este lanzamiento:

leer más

por rafaelma el 08 febrero 2013 08:29

11 diciembre 2012

Fabian Barrera

Evitar errores en búsquedas sobre campos de texto con mayúsculas y minúsculas en PostgreSQL

Si los campos de texto se almacenan con mezclas de mayúsculas y minúsculas, las búsquedas se ven afectadas y podrían no entregar los resultados que esperamos. Para ilustrarlo supongamos que tenemos una tabla llamada 'persona' con un campo 'nombre', en el que almacenaremos la información introducida por un usuario mediante un formulario y que no procesaremos dicho campo, por lo que el usuario podrá ingresar el texto usando mayúsculas y minúsculas. Luego de varios ingresos tendremos los siguientes datos:

SELECT id, nombre FROM prueba_persona;
 id | nombre
----+---------------------
  1 | CARLOS PEREZ
  2 | Carmen Pereira
  3 | Ricardo Gonzalez
  4 | gonzalo Perez
  5 | PERICLES RICAURTE
  6 | perico portocarrero
(6 filas)

Con estos datos, si quisiéramos obtener los nombres que contengan la cadena 'car' esperaríamos obtener las filas 1, 2, 3 y 6, pero si efectuamos la consulta obtendremos lo siguiente:

SELECT id, nombre FROM persona WHERE nombre LIKE '%car%';
 id | nombre
----+---------------------
  3 | Ricardo Gonzalez
  6 | perico portocarrero
(2 filas)

Porque el motor de Bases de Datos distingue entre mayúsculas y minúsculas como caracteres diferentes. Una solución rápida consiste en modificar la consulta así:

SELECT id, nombre FROM persona WHERE lower(nombre) LIKE '%car%';
 id | nombre
----+---------------------
  1 | CARLOS PEREZ
  2 | Carmen Pereira
  3 | Ricardo Gonzalez
  6 | perico portocarrero
(4 filas)

En esta consulta estamos primero pasando el atributo a minúsculas y sobre el texto modificado efectuamos la consulta. De este modo podremos obtener los datos que realmente buscamos. Hay que aclarar que no se modifican los valores del atributo dentro de la tabla sino en el búfer de búsqueda.

Sin embargo, si hacemos un uso recurrente de este tipo de consultas, es mejor usar un método más eficiente. Si no importa la mezcla de minúsculas y mayúsculas podemos modificar el valor del campo en un trigger antes de hacer el INSERT y almacenar el texto en minúsculas:

CREATE OR REPLACE FUNCTION modificar_nombre_persona() RETURNS TRIGGER AS $$
BEGIN

  NEW.nombre := lower(NEW.nombre);
  RETURN NEW;

END
$$
LANGUAGE 'plpgsql';

CREATE TRIGGER persona_antes_insertar BEFORE INSERT ON persona FOR EACH ROW EXECUTE PROCEDURE modificar_nombre_persona();

De este modo al ingresar los datos éstos quedarán almacenados así:

SELECT id, nombre_busquedas FROM prueba_persona;
 id | nombre_busquedas
----+---------------------
  1 | carlos perez
  2 | carmen pereira
  3 | ricardo gonzalez
  4 | gonzalo perez
  5 | pericles ricaurte
  6 | perico portocarrero
(6 filas)

Y al hacer la misma búsqueda obtendremos los siguiente resultados:

SELECT id, nombre FROM persona WHERE nombre LIKE '%car%';
 id | nombre_busquedas
----+---------------------
  1 | carlos perez
  2 | carmen pereira
  3 | ricardo gonzalez
  6 | perico portocarrero
(4 filas)

Pero si es necesario conservar la forma escrita por el usuario, podemos crear un campo adicional, en el que almacenaremos el valor en minúsculas y no alteraremos el campo original.

ALTER TABLE persona ADD nombre_busquedas varchar(255);

CREATE OR REPLACE FUNCTION crear_nombre_busquedas_persona() RETURNS TRIGGER AS $$
BEGIN

  NEW.nombre_busquedas := lower(NEW.nombre);
  RETURN NEW;

END
$$
LANGUAGE 'plpgsql';

CREATE TRIGGER persona_antes_insertar BEFORE INSERT ON persona FOR EACH ROW EXECUTE PROCEDURE crear_nombre_busquedas_persona();

En este caso los datos quedarían almacenados así:

SELECT * FROM persona;
 id | nombre              | nombre_busquedas
----+---------------------+---------------------
  1 | CARLOS PEREZ        | carlos perez
  2 | Carmen Pereira      | carmen pereira
  3 | Ricardo Gonzalez    | ricardo gonzalez
  4 | gonzalo Perez       | gonzalo perez
  5 | PERICLES RICAURTE   | pericles ricaurte
  6 | perico portocarrero | perico portocarrero
(6 filas)

Y la consulta se haría así:

SELECT id, nombre FROM persona WHERE nombre_busquedas LIKE '%car%';
 id | nombre
----+---------------------
  1 | CARLOS PEREZ
  2 | Carmen Pereira
  3 | Ricardo Gonzalez
  6 | perico portocarrero
(4 filas)

Mediante cualquiera de estas dos formas evitaremos el uso de funciones adicionales en la consulta y obtendremos un poco más de eficiencia.

Eso es todo!

PDTA: También habría que ejecutar los triggers antes de actualizar.

por Fabian Barrera (noreply@blogger.com) el 11 diciembre 2012 04:28

10 diciembre 2012

Fabian Barrera

Obtener el último registro insertado en una tabla en PostgreSQL

Podría parecer algo muy sencillo pero la verdad es que a veces puede no serlo tanto, sobretodo si no tuvimos en cuenta esto en el diseño de la BD. Según la tabla podemos encontrarnos con 2 posibilidades:

  • Tablas sin campo único autoincrementable
  • Tablas con campo único autoincrementable

Veamos cada una en detalle:


Tabla sin campo único autoincrementable


Si no incluimos un campo autoincrementable en la tabla, puede resultar muy tedioso ya que PostgreSQL reordena los datos cada que hay una actualización de un registro, por lo que no siempre obtendremos el listado en el mismo orden, pero dependiendo de la situación tenemos varias opciones:
  • Usar OIDs: Por defecto PostgreSQL agrega este campo 'oculto' a cada registro pero en la misma documentación vemos que no son fiables como identificador, además habría que habilitarlos al crear la tabla ya que desde la versión 8.1 los OIDs están deshabilitados por defecto.
    SELECT * FROM tabla ORDER BY oid DESC LIMIT 1;
  • Consulta inmediatamente después de insertar el registro: Apenas insertamos el registro podemos obtener el último registro con la siguiente consulta:
    SELECT * FROM tabla LIMIT 1;
    Pero no funcionará después de que se hagan otro tipo de actualizaciones sobre la tabla, así que tampoco sirve mucho.
  • Usar claúsula RETURNING en el INSERT: Igual que el anterior sólo sirve inmediatamente después de la inserción del registro.

Tabla con campo único autoincrementable


En este caso todo es mucho más sencillo. Suponiendo que el campo se llama id tenemos varias opciones según lo que querramos:
  • Obtener el último ID insertado mediante consulta: Si queremos conocer el último id insertado en la tabla usaremos la función agregada MAX:
    SELECT MAX(id) FROM tabla;
  • Obtener el último registro insertado: Si lo que queremos es la tupla completa, con varios o todos sus campos las consultas que usaremos son estas:
    SELECT * FROM tabla ORDER BY id DESC LIMIT 1;
    SELECT id, campo1, campo2 FROM tabla ORDER BY id DESC LIMIT 1;

    Esta consulta simplemente ordena por la llave primaria autoincrementable en orden descendente y entrega sólo un resultado.
  • Obtener el último ID insertado en una sesión de trabajo: Al estar vinculado con una secuencia cada campo autoincrementable (tipo SERIAL) podemos usar las funciones de manipulación de secuencias. De estas podemos usar la función lastval() que nos entregará el valor más reciente de cualquier secuencia en la sesión actual. De este modo podemos, por ejemplo, asignar su valor a una variable si estamos en una función:
    ultimo_id := lastval();

Por esta y otras razones es una buena práctica usar llaves primarias autoincrementables en las tablas.

por Fabian Barrera (noreply@blogger.com) el 10 diciembre 2012 09:33

Construir SQL dinámicos en PostgreSQL con PL/pgSQL

A veces queremos ejecutar un SQL dentro de una función (como en un trigger) en el que los nombres de los campos o de la tabla a consultar varian, es decir que es dinámico.

Si estamos usando el lenguaje procedimental de PostgreSQL (PL/pgSQL), esto puede hacerse a través de concatenación de cadenas de texto.

Para el ejemplo, supongamos que queremos una función que nos genere el código siguiente para un campo y tenemos la misma estructura para diferentes tablas, así que queremos que la función sea reutilizable. El código es muy sencillo: tomar el último valor para el campo, sumarle 1 y devolver el resultado:

CREATE OR REPLACE FUNCTION generar_siguiente_codigo(tabla_nombre varchar, col1_nombre varchar, col2_nombre varchar, col1_valor int) RETURNS smallint AS $$
DECLARE
max_cod SMALLINT;
sig_cod SMALLINT;
BEGIN

EXECUTE 'SELECT MAX('|| col2_nombre ||') FROM '|| tabla_nombre::regclass ||' WHERE '|| col1_nombre ||' = $1'
INTO max_cod
USING col1_valor;

IF max_cod IS NULL THEN
max_cod := 0;
END IF;

sig_cod := max_cod + 1;

RETURN sig_cod;
END
$$
LANGUAGE 'plpgsql';

El comando EXECUTE es el que nos permite ejecutar el SQL creado, que es sólo una concatenación de textos mediante el operador ||. Es necesario usar el identificador regclass para el nombre de las tablas o el SQL no funcionará.

Y eso es todo.

por Fabian Barrera (noreply@blogger.com) el 10 diciembre 2012 09:33

Uso de LIKE con campos de tipo numérico en PostgreSQL

El operador LIKE de SQL sirve para comparar expresiones según un patrón (más info acá). Pero funciona sólo con campos tipo texto (CHAR, VARCHAR, TEXT). Si se quiere hacer una comparación sobre un campo tipo INTEGER no va a funcionar (tuve que hacer dicha comparación al configurar un campo de formulario con autocompletado con Symfony).

Sin embargo se puede hacer y el truco es muy sencillo, ya que simplemente debemos 'convertir' el campo de tipo entero a una cadena de texto. Esto se hace con la función TO_CHAR. Veamos un ejemplo de consulta sencilla con esta función:

SELECT codigo FROM tabla WHERE TO_CHAR(codigo, '9999') LIKE '%texto%';

Acá le estoy dando formato de 4 dígitos al código pero si hay códigos más largos habrá que usar más dígitos en el formato de TO_CHAR:

SELECT codigo FROM tabla WHERE TO_CHAR(codigo, '9999999999') LIKE '%texto%';

La función entregará espacios vacíos para los números que tengan menos dígitos. Si queremos eliminarlos podemos hacerlo con la función TRIM:

SELECT codigo FROM tabla WHERE TRIM(TO_CHAR(codigo, '9999999999')) LIKE '%texto%';

Como dato curioso de esta última consulta debo decir que al usar esta consulta con el widget de autocompletado de sfFormExtraPlugin no funciona correctamente, ya que no entrega todos los resultados, así que he tenido que dejar la forma más sencilla de la consulta.

por Fabian Barrera (noreply@blogger.com) el 10 diciembre 2012 09:33

División entre enteros en PL/pgSQL

La división entre enteros elimina automáticamente la parte decimal del resultado. Esto puede ser contraproducente si necesitamos cálculos que hagan uso de la parte decimal, incluso si simplemente queremos redondear y obtener un entero, ya que obtendremos un resultado erróneo cuando la parte decimal sea mayor a 0.5. Consideremos por ejemplo que vamos a almacenar el valor del salario mensual de un contrato y queremos calcular el valor del día como valor entero y guardarlo para posteriores operaciones:

DECLARE
  ...
BEGIN
  ...
  NEW.salario_base_diario := NEW.salario_base_mensual / 30;


Si el salario_base_mensual es de 348, dividiendo en 30 obtendremos 11.6, al ser salario_base_diario entero esperaríamos tener un valor de 12, pero no. Postgres simplemente desprecia la parte decimal con lo que el valor que obtendremos será 11, lo cual puede generar muy malos resultados después. Para obtener un resultado adecuado es mejor almacenar una o varias de las variables usadas como tipo NUMERIC aunque sean enteros, de este modo el resultado será NUMERIC y podremos hacer el redondeo adecuado, así:

DECLARE
  ...
  var_nuevo_salario_base_mensual NUMERIC;
BEGIN
  ...
  -- Redondear el salario mensual a dos dígitos decimales
  var_nuevo_salario_base_mensual := round(NEW.salario_base_mensual, 2);
  NEW.salario_base_diario := round(var_nuevo_salario_base_mensual / cfg_dias_mes);


Con este pequeño cambio obtendremos lo que queremos, de modo que: 348/30 = 11.60. Y este resultado será redondeado correctamente a 12.

por Fabian Barrera (noreply@blogger.com) el 10 diciembre 2012 09:33

Error al cargar backup de PostgreSQL 9.1 a 8.4 con funciones que usen PL/pgsql

Al querer cargar un archivo de backup desde una versión más reciente a una anterior siempre surgen problemas. Este es uno de ellos si cargamos un archivo de backup hecho con pg_dump desde la versión 9.1 a una versión anterior y tenemos funciones (tal vez triggers) programados con PL/pgsql. A mí me sucede porque mi máquina de trabajo tiene un Fedora 17 y mi servidor tiene Debian 6. Al intentarlo aparecerá el siguiente error:

ERROR: error de sintaxis en o cerca de «EXTENSION»
LÍNEA 1: CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalo...

Y no creará las funciones que dependan de este lenguaje.

Ahora PostgreSql introdujo el comando CREATE EXTENSION para reemplazar varias tareas. Este comando no existe en las versiones anteriores a la 9.1, pero si no observamos más errores, corregirlo es sencillo: editamos nuestro archivo de backup y eliminamos las siguientes líneas:

CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';

Y las reemplazamos por la siguiente:

CREATE LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler LANCOMPILER 'PL/pgSQL';

Y listo! Claro está que ésto sólo corregirá el error para PL/pgSQL y si tenemos más problemas de compatibilidad con CREATE EXTENSION habrá que buscar la solución para cada uno de ellos.

por Fabian Barrera (noreply@blogger.com) el 10 diciembre 2012 09:32

Consideraciones al renombrar una tabla en PostgreSQL

Renombrar una tabla es algo sencillo, simplemente hacemos uso del comando ALTER TABLE:

ALTER TABLE nombre_actual RENAME TO nuevo_nombre;

Sin embargo, este comando sólo renombra la tabla mientras los nombres de sus índices, secuencias, llaves foráneas y otros constraints permanecen iguales. Esto podría no ser un problema, pero si estos nombres son parte del diseño de la BD y queremos cambiarlos, deberemos renombrar los índices y secuencias uno por uno:

ALTER INDEX nombre_actual_pkey RENAME TO nuevo_nombre_pkey;
ALTER SEQUENCE nombre_actual_id_seq RENAME TO nuevo_nombre_id_seq;

y recrear las llaves foráneas y constraints:

ALTER TABLE nombre_actual DROP CONSTRAINT nombre_actual_campo_fkey;
ALTER TABLE nombre_actual ADD CONSTRAINT nuevo_nombre_campo_fkey REFERENCES otra_tabla(id);

Otra opción es hacer un backup de la tabla, eliminarla, recrearla con los nombres que deseamos y cargar el backup de datos.

Ahora, aunque el renombrar la tabla no renombra sus lláves foráneas SÍ cambia la definición de llaves foráneas que dependan de la tabla renombrada, por lo que se conserva la integridad referencial. Por ejemplo si tenemos la tabla 'otra_tabla' que tiene una llave foránea al campo 'nombre_actual.id', al renombrar esta tabla la llave foránea dentro de 'otra_tabla' es redefinida para referenciar al campo 'nuevo_nombre.id'.

por Fabian Barrera (noreply@blogger.com) el 10 diciembre 2012 09:31

27 octubre 2012

Rafael Martinez

PGconf Europa 2012 ha finalizado

comunidad

#pgconfeu - Un año más la conferencia PostgreSQL Europa 2012 ha sido todo un exito. 6 entrenamientos y 45 presentaciones han mantenido a casi 300 participantes ocupados durante los dias que ha durado esta conferencia en Praga, la capital de la República Checa.

A continuación teneis un resumen de las sesiones a las que yo he podido asistir.

leer más

por rafaelma el 27 octubre 2012 07:29

16 octubre 2012

Rafael Martinez

Conferencia PostgreSQL Europa 2012

comunidad

Queda una semana para la conferencia PostgreSQL Europa 2012. Este año se celebra en Praha, la capital de la República Checa durante los dias 23 al 26 de octubre.

Más de 40 presentaciones y varias sesiones de entrenamiento están programadas durante estos dias. PostgreSQL-es estará representado en la conferencia y tenemos planeado informaros sobre el desarrollo de la misma.

Nos vemos en Praha.
--
Rafael Martinez Guerrero
PostgreSQL-es

por rafaelma el 16 octubre 2012 09:13

21 septiembre 2012

Fabian Barrera

Porqué usar llaves primarias autoincrementables

En un post anterior explicaba una ventaja de los campos autoincrementables, pero además de ésta existen otras razones que hacen que sea una buena práctica incluir un campo autoincrementable como llave primaria (PK) en cada tabla.

Incluir campos autoincrementables como llaves primarias en cada tabla de una base de datos tiene varias ventajas, que hacen que usarlas sea una buena práctica. Veamos algunas de esas buenas razones:

  1. Facilita la obtención del último registro insertado.

    Tener un campo autoincrementable en una tabla, hace mucho más sencillo este procedimiento en algunos casos, como ya lo expliqué en este post anterior.

  2. Permite conservar la unicidad de los registros mientras definimos o cambiamos el valor de un campo único.

    Supongamos que tenemos la tabla automovil, definida así:

    CREATE TABLE automovil (
    placa char(6) PRIMARY KEY,
    marca varchar(50),
    pasajeros int );

    Si por alguna razón nos encontramos con un valor incorrecto para la llave primaria de un nuevo registro, podemos igual hacer la inserción del registro y dejar pendiente la definición del valor para el campo placa si redefinimos la tabla así:

    CREATE TABLE automovil (
    id serial,
    placa char (6) UNIQUE,
    marca varchar(50),
    pasajeros int );

    Si no queremos permitir valores nulos para el campo placa tendríamos que definirlo como NOT NULL.

  3. Permite conservar la integridad referencial entre dos o más tablas relacionadas.

    Siguiendo con el ejemplo anterior, supongamos que tenemos la tabla automovil relacionada con la tabla propietario, de la siguiente forma:

    CREATE TABLE propietario (
    documento_identificacion char(9) PRIMARY KEY,
    nombres varchar(100),
    apellidos varchar(100),
    direccion varchar(100),
    telefono varchar(100));

    CREATE TABLE automovil (
    placa char(6) PRIMARY KEY,
    marca varchar(50),
    pasajeros int
    propietario char(9) REFERENCES propietario(documento_identificacion));

    Si tuviéramos que cambiar el valor del campo documento_identificacion para un registro en propietario, tendríamos que cambiarlo también en automovil. Esto puede hacerse mediante el uso del comportamiento CASCADE en el evento ON UPDATE en la definición de la llave foránea, pero se estaría ejecutando una operación adicional en la base de datos por cada tabla que tenga una referencia con ese registro, y de hecho hay tablas que suelen tener muchas refencias, por lo que sería una carga adicional innecesaria que puede evitarse.

    Al redefinir las tablas usando llaves primarias autoincrementables podremos hacer cambios sobre los campos únicos sin tener que preocuparnos por la integridad referencial y las consultas adicionales:

    CREATE TABLE propietario (
    id serial PRIMARY KEY,
    documento_identificacion char(9) UNIQUE,
    nombres varchar(100),
    apellidos varchar(100),
    direccion varchar(100),
    telefono varchar(100));

    CREATE TABLE automovil (
    id PRIMARY KEY
    placa char(6) UNIQUE,
    marca varchar(50),
    pasajeros int
    propietario_id int REFERENCES propietario(id));

Además de estas hay otras buenas razones, así que por qué no hacerlo?

por Fabian Barrera (noreply@blogger.com) el 21 septiembre 2012 06:43

10 septiembre 2012

Rafael Martinez

Necesitamos más contenidos en Planeta PostgreSQL-es

comunidad

Planeta PostgreSQL-es es una página que se actualiza automáticamente con los contenidos que algunos colaboradores y usuarios de PostgreSQL generan en sus propios blogs y páginas web.

Todos los blogs que quieran formar parte de "Planeta PostgreSQL-es" deben ser sobre PostgreSQL o temas relacionados. Si escribes sobre otros temas en tu blog, registra tus entradas sobre PostgreSQL en una categoría específica y usa el RSS de esta categoría en "Planeta PostgreSQL-es".

leer más

por rafaelma el 10 septiembre 2012 01:50

Lanzamiento de PostgreSQL 9.2

postgres-logo

El Grupo Global de Desarrollo de PostgreSQL ha anunciado PostgreSQL 9.2, la última versión del líder en bases de datos de código abierto.

Desde el anuncio del beta en mayo, los comercializadores y desarrolladores han elogiado a esta versión como un salto adelante en el rendimiento, la escalabilidad y la flexibilidad. Se esperan cifras récord de usuarios que migrarán a esta versión.

Entra las características más importantes a destacar en esta versión, podemos citar:

por rafaelma el 10 septiembre 2012 01:19

20 agosto 2012

Rafael Martinez

Nuevas versiones de PostgreSQL disponibles

postgres-logo

El proyecto PostgreSQL ha lanzado nuevas versiones menores de todas las series activas de PostgreSQL. Esta actualización arregla entre otras cosas un problema de seguridad de clase C (escalada de privilegios una vez conectados con un usuario/clave validos) con libxml2 y libxsl.

Las nuevas versiones disponibles son 9.1.5, 9.0.9, 8.4.13 y 8.3.20.

Anuncio oficial de este lanzamiento:
http://www.postgresql.org/about/news/1407/

Más información sobre las versiones lanzadas:
http://www.postgresql.org/docs/current/static/release.html

Descargas:
http://www.postgresql.org/download/

leer más

por rafaelma el 20 agosto 2012 07:26

13 julio 2012

Fabian Barrera

Instalación y arranque de PostgreSQL en Fedora 17

Para usar el mejor servidor de Bases de Datos SQL en la nueva versión de Fedora deberemos llevar a cabo un par de sencillos pasos, que varían un poco respecto a la versión anterior, estos comandos habrá que ejecutarlos como root o mediante el comando sudo:
  • Instalar:

    # yum install postgresql postgresql-server

  • Inicializar la BD, usando el nuevo script postgresql-setup:

    # postgresql-setup initdb

  • Iniciar el daemon:

    # service postgresql start

  • Arrancar el daemon por defecto en los niveles de inicio 2, 3 y 5:

    # chkconfig --levels 235 postgresql on

Luego deberemos realizar la configuración básica del mismo modo que en versiones anteriores de Fedora y que describo en este post.

Eso es todo, ahora podremos trabajar sin problemas.

por Fabian Barrera (noreply@blogger.com) el 13 julio 2012 05:52