Common Table Expression (CTE): la sentencia WITH en PostgreSQL.

Hace tiempo escribí una entrada sobre el uso de CTE en SQL-Server de Microsoft y no hace mucho en dicha entrada me preguntaron si podría usarse también una CTE en PostgreSQL. La respuesta es que sí, existe este recurso también en ese sistema gestor de bases de datos.

Sintaxis básica de una CTE

Recuerda, una CTE es un artefacto que nos permite mantener en memoria el resultado de una consulta para poder utilizarlo como si se tratase de una tabla o vista más.

En PostgreSQL usaría la misma sintaxis que en SQL-Server: tras la instrucción WITH definimos el nombre de la CTE y podemos opcionalmente agregar también los nombres que queramos dar a las columnas de la tabla que devolverá como resultado (si no lo hacemos entonces se usarán por defecto los nombres de las columnas que traigamos en la consulta). Dentro del cuerpo de la instrucción WITH definimos la consulta que queramos usar en la CTE. Finalmente ya podremos usar nuestra CTE dentro de una consulta. En fin, que lo básico sería tal que así:

WITH cte_name (column_list) AS (
    Select * from TablaQueNecesitemos
)

El mismo ejemplo que usé en la entrada sobre SQL-Server nos vale para aquí, una CTE sobre dos tablas (vendedores y ventas) para ver el total de ventas de cada uno ese año:

WITH Ventas_CTE (IdVendedor, NombreVendedor, TotalVendido)  
AS  
(  
    SELECT 
      v.Id as IdVendedor, 
      v.Nombre as NombreVendedor, 
      SUM(vt.Importe) AS TotalVentas 
    FROM Vendedores v inner join ventas vt on v.Id = vt.IdVendedor
    WHERE YEAR(vt.Fecha)=2018
)  

Después podríamos usar esa CTE como una tabla más en cualquier consulta de SELECT, INSERT,UPDATE o DELETE. Recordad que como en SQL-Server no podremos usar cláusulas coo ORDER BY o FOR BROWSE, algo que tampoco tendría mucho sentido por otra parte.

¿Por qué usar una CTE?

La misma pregunta que nos hacíamos en el primer artículo. Hay motivos varios para usar una CTE con PostrgreSQL:

  • Hacer más legible y más entendible una consulta compleja, permitiéndonos prescindir de variables de tabla y subconsultas, consiguiendo un código más ordenado y limpio sin penalizar el rendimiento.
  • La posibilidad de crear consultas recursivas (un tema del que prometí escribir hace dos años y se me pasó)
  • La posibilidad de usar funciones de agregado o funciones ventana y poder operar con ellas después.

SQL: Formas Normales

Recuperados ya del fin de semana de rock and roll vamos a volver al código con algo de SQL teórico: la normalización de datos. El diseño lógico de las tablas y sus relaciones es fundamental para la optimización de una base de datos. Existen cinco reglas de normalización que debemos cumplir para aseverar que nuestra base de datos SQL está normalizada, aunque es cierto que hay quien considera que la cuarta y la quinta son rizar el rizo y que con cumplir la tres primeras generalmente ya tenemos una base de datos normalizada. Estas son las cinco formas normales:

  1. Primera Forma Normal: La primera forma requiere la eliminación de todas las columnas duplicadas de una tabla, la separación en otras tablas de esos datos que se duplicarían y la identificación de cada tabla con una atributo de clave primaria. Por ejemplo, si tenemos una tabla donde registramos ventas no guardamos el nombre y el precio del producto vendido en ella varias veces, sino que tendremos una tabla de productos con esos datos separado de la tabla de ventas, y ambas tendrían claves primarias que identifican a cada fila.
  2. Segunda forma Normal: Implica que se cumpla lo dicho en la primera forma normal y que, además, se creen relaciones entre tablas a través de claves externas. Es decir, la tabla Ventas del ejemplo anterior incluye como Clave Externa un valor único que lo relaciona con la tabla Productos, generalmente su clave primaria.
  3. Tercera Forma Normal: Esta norma implica que se cumplan las dos anteriores y que, además, todas las columnas de un registro deben hacer referencia únicamente a la clave primaria, y además elimina todos los atributos derivados. Volvemos al ejemplo: la tabla Productos nos dará el nombre del producto, su precio, en qué almacén se guarda y su fecha de caducidad. No tendremos, por ejemplo, un registro para decir en qué piso del almacén se guarda, ya que ese dato sería de la tabla Almacén. Tampoco tendríamos una columna con los días que faltan hasta que caduque, ya que ese sería un atributo derivado que podemos calcular con la fecha de caducidad.
  4. Cuarta Forma Normal: Agrega un requisito adicional, que es la eliminación de cualquier dependencia multivaluada en las relaciones. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia.
  5. Quinta Forma Normal: Rizando el rizo, vendría a decir que sólo se podrían realizar relaciones entre tablas utilizando claves candidatas, con la idea de reducir la redundancia de datos entre múltiples tablas.

A la hora de normalizar bases de datos hay una frase en inglés que lo resume todo: «The key, the whole key, and nothing but the key.» En la propia web de Microsoft la primera recomendación que dan para mejorar el rendimiento de SQL-Server y tener un diseño eficiente de la base de datos es usar un índice autonumérico como clave primaria de cada tabla, identificando así de forma unívoca cada registro y facilitando la relación entre ellos.

PostgreSQL: Obtener todas las fechas que existen entre dos fechas dadas

El otro día veíamos cómo crear en SQL-Server una tabla con todas las fechas entre dos fechas dadas. Hoy vamos a ver cómo hacer un simple select valiéndonos de la función generate_series() para obtener todas las fechas comprendidas entre dos fechas dadas con PostgreSQL

select i::date from generate_series('2017-06-01', 
  '2017-07-31', '1 day'::interval) i

PostgreSQL: Consulta para saber en qué tabla está una columna

Lo hicimos en Oracle, en SQL-Server y en MySQL. No podíamos dejarnos PostgreSQL ¿cómo podemos saber en qué tabla está una columna sabiendo sólo el nombre de dicha columna?

Pues con una consulta sobre la vista columns, que contiene información sobre las columnas de todas las tablas y vistas. Veamos cómo sabríamos en qué tabla está la columna «NombrePaciente» (por poner un ejemplo práctico):

Select table_name
from columns
where column_name like 'NombrePaciente'

En vuestro caso cambiáis NombrePaciente por el nombre de columna que corresponda.

PostgeSQL: Calcular una edad a partir de una fecha.

No hace mucho veíamos cómo calcular una edad en SQL-Server. Vamos ahora con otro SGBD ¿Cómo lo hago en Postgres? Pues con mucha menos dificultad, porque este gestor incluye ya una función integrada para el cálculo de edades, presente al menos desde la versión 9 (no se si antes) llamada age().

La función puede ser llamada con uno o con dos argumentos, siempre del tipo timestamp, y devuelve el interváluo entre ambos. Para el ejemplo imaginemos una tabla llamada clientes donde tenemos un campo FechaNac con la fecha de nacimiento guardada.

/*Con el primer ejemplo
pasando sólo una fecha
cogería la edad a día de hoy
de alguien nacido en esa fecha*/
Select age(timestamp FechaNac) from clientes

/*Con el segundo ejemplo
pasando dos fechas
cogería la edad que una
persona nacida en la fecha 2
tenía en la fecha 1*/

Select age(timestamp '2014-01-01',timestamp FechaNac) from clientes

Script para gestión de backups de PostgreSQL en FreeBSD

No recuerdo si había comentado que estaba en plena migración tecnológica laboral, trabajando con el SGBD libre PostgreSQL y el sistema operativo (libre, of course) FreeBSD. Y el primero de los trasteos era simple ¿cómo automatizo los backups? Ya habíamos hablado de este tipo de cuitas alguna vez por aquí, así que vamos a ver cómo con un script, y haciendo uso de Cron, podemos lograrlo:

#!/bin/sh
# pgsql backups --datosde conexion
db_user="tu_usuario"
db_name="tu_base_de_datos"
db_dumpdir="/var/backups/carpeta"
date_format="`date +%Y-%m-%d.%H:%M`"

#ARRIBA CAMBIA LOS EJEMPLOS POR LOS DATOS QUE CORRESPONDAN. 
 
# BORRAMOS LOS BACKUPS MÁS VIEJOS
# PARA NO SATURAR
# EN ESTE CASO, LOS QUE TENGAN MÁS DE
# 4 SEMANAS

expire_time="+4w"
 
# Begin Script #
/usr/local/bin/pg_dump -U $db_user $db_name -f "$db_dumpdir/$db_name-$date_format.pgsql"
/usr/bin/find $db_dumpdir -d 1 -Btime $expire_time -delete

Con este ya tenemos un script que nos genera un backup de la base de datos en nuestra carpeta de copias de seguridad y además borra los que tengan más de cuatro semanas, para que no saturemos el disco duro. Y ahora, como dijimos antes, necesitamos Crontab para automatizar la copia. Asumamos que guardamos el script en la dirección /usr/local/scripts/pg_backup.sh, porque somos gente ordenadita (al menos a la hora de organizar discos duros). En nuestro caso ejecutaremos el script cada 6 horas:

# crontab -e
* /6 * * * /usr/local/scripts/pg_backup.sh > /dev/null 2>&1

Y con esto ya tenemos la cuestión de automatizar las copias de seguridad solventada.

Consulta SQL para conocer el número de campos de una tabla

Por avatares del destino hoy estaba modificando una página en ASP clásico y necesitaba saber el número de campos que tenía una tabla. Basta con una consulta para tener estos datos:

SELECT Table_Name, COUNT(*) As NumeroCampos
FROM Information_Schema.Columns
WHERE Table_Name = 'nombre_de_la_tabla'
GROUP BY Table_Name;

Si queréis saber el de todas las tablas de la base de datos podéis hacer lo siguiente:

SELECT Table_Name, COUNT(*) As NumeroCampos
FROM Information_Schema.Columns
GROUP BY Table_Name
ORDER BY Table_Name

Evitar SQL-injection en PHP

Los ataques SQL-Injection son unos de los más habituales en el mundo web. Aquí vamos a ver una serie de consejos para evitar estos agujeros en la seguridad:

Lo primero es seguir una serie de consejos a nivel de administración, como limitar los permisos del usuario a nivel de base de datos. Por ejemplo, en la mayoría de aplicaciones web lo habitual es que no tenga que utilizarse DROP, por lo que por seguridad sería mejor no permitir ya al usuario hacerlo. También sería interesante no dar información extra al atacante evitando sacar en pantalla los errores de la base de datos. En ese caso lo ideal es capturar el error haciendo uso de exception. Tampoco hay que confiarlo todo a las validaciones por javascript, porque el atacante puede saltárselas desactivándolo desde el navegador, por lo que mejor hacer las validaciones del lado del servidor. Y finalmente escapar las comillas con msqli_real_scape_string (en caso de que usemos MySQL), pg_scape_string (en caso de PostgreSQL) o addslashes (por si utilizamos otro SGBD). También podemos utilizar htmlentities para convertir los textos en entidades html, como un plus a la seguridad. Abajo un simple ejemplo:


<?php

try{
  $query = sprintf("SELECT * FROM users WHERE id=%d", mysqli_real_escape_string($id));
  $query = htmlentities($query);
  mysqli_query($query);
}catch(Exception $e){
    echo('Lo sentimos, ha habido un error en la conexión');
}
?>

Como medida extra se podrían utilizar expresiones regulares para evitar la inserción de ciertas palabras (SELECT, DROP, UNION…), si bien puede resultar poco práctico, sobre todo si tu software está destinado al mercado británico.

Pero si todo esto te parece lioso, hay una alternativa: la clase PDO. Dicha clase nos facilitará mucho la vida a la hora de trabajar con bases de datos, ya que nos permite abstraernos del SGDB que estemos utilizando. Si por ejemplo, en una página donde no utilices PDO o algo similar sino el mysql_connect simple, decides migrar tu web de MySQL a PostgreSQL tendrías que cambiar todos los métodos del conector de MySQL por los métodos de PostgreSQL. Con PDO bastaría con que cambiaras una sola línea de código, concretamente la de la creación del objeto PDO, y el resto de la aplicación seguiría funcionando. PDO además te permitirá usar consultas parametrizadas (como los Prepared Statements de java) o realizar transacciones. En fin, en el enlace de arriba tenéis todo el manual de PDO para estudiarlo si queréis. Ahora vamos con un simple ejemplo de Prepared Statement, para que veáis lo sencillo que es (dando por sentado para el ejemplo que ya hemos creado el objeto PDO, tal cual está explicado en el manual del enlace).


<?php
  $prepared_statement = $pdo->prepare("SELECT name FROM usuarios WHERE id = :id");/*preparamos la consulta*/
  $prepared_statement->bindParam(':id', $_GET['id'], PDO::PARAM_INT); /*Le pasamos el parámetro, asociado al parámetro de la consulta y definiendo su tipo (si no, por defecto lo trata como string)*/
  $prepared_statement->execute(); /*ejecutamos*/
  $prepared_statement = $statement->fetch(); /*recogemos los resultados, como un array. Se pueden utilizar parámetros para especificar otro tipo de respuesta, como por ejemplo PDO::FETCH_ASSOC para obtener un array asociativo*/
?>

Y con estos breves consejos lograrás que tu página sea más segura. El consejo: utiliza PDO, por ahorrarte comeduras de cabeza, por seguridad y por portabilidad de tu código.

Instalación de OpenERP en Ubunto o Debian

OpenERP es una de las soluciones empresariales más populares dentro del software libre. Con una enorme escalabilidad, nos permite modificarlo para crear módulos específicos para las necesidades de una empresa determinada. Utiliza PostgreSQL como SGBD y está programado en Python, por lo que el conocimiento de este lenguaje será clave para la realización de módulos, aunque si ya has trabajado con C, Java o C# la sorpresa será mínima, incluso para programadores PHP (programadores, no diseñadores gráficos que hacen webs a base de Dreamweaver y módulos prefabricados). Pero el desarrollo de módulos puede que lo toquemos más adelante, hoy vamos con la instalación del servidor web de OpenERP 6.0 sobre Ubuntu o sobre Debian. Mayormente es una traducción de este artículo en inglés… bueno, una adaptación explicada con mis palabras.

Vamos al principio, first step, preparar el equipo para toda la instalación: instalar un servidor, crear el usuario, instalar Postgres… Ya sabes, por partes te lo pongo en el siguiente ejemplo:

#Preparar el servidor
apt-get install openssh-server denyhosts
apt-get update
apt-get dist-upgrade

#Crear el usuario
adduser –system –home=/opt/openerp –group openerp passwd openerp

#Instalamos PostgreSQL, creamos la base de datos y el usuario
apt-get install postgresql
su – postgres
createuser –createdb –username postgres –no-createrole –pwprompt openerp
exit

#Instalamos los paquetes y librerías de Python, que falta nos van a hacer (tochazo del 15)

apt-get install python python-psycopg2 python-reportlab python-egenix-mxdatetime python-tz python-pychart python-mako python-pydot python-lxml python-vobject python-yaml python-dateutil python-pychart python-pydot python-webdav

apt-get install python-cherrypy3 python-formencode python-pybabel python-simplejson python-pyparsing

Ahí estamos, todo el equipo listo para instalar OpenERP. La cuestión es descargar el server y el cliente web, descomprimir todo, dar permisos… En el ejemplo lo tenéis todo:


#Descargamos ambos paquetes
wget http://www.openerp.com/download/stable/source/openerp-server-6.0.3.tar.gz
wget http://www.openerp.com/download/stable/source/openerp-web-6.0.3.tar.gz

#Descomprimir, cambiar permisos... etc:
cd /opt/openerp
tar xvf ~/openerp-server-6.0.3.tar.gz
tar xvf ~/openerp-web-6.0.3.tar.gz
chown -R openerp: *
cp -a openerp-server-6.0.3 server
cp -a openerp-web-6.0.3 web

Ahora toca tocar el archivo de configuración del servidor, cambiando el password de la base de datos. En la carpeta /etc/ le metéis mano a openerp-server.conf con el editor Nano. Busca la línea db_password y allí añade la contraseña buena.

Tras esto, toca cambiar al propietario:

sudo chown openerp:root /etc/openerp-server.conf
sudo chmod 640 /etc/openerp-server.conf

Ahora toca crear, o modificar, el script para que arranque con el sistema, modificando /etc/initd.d/openerp-server, tal que así:

#!/bin/sh

### BEGIN INIT INFO
# Provides:             openerp-server
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Should-Start:         $network
# Should-Stop:          $network
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    Enterprise Resource Management software
# Description:          Open ERP is a complete ERP and CRM software.
### END INIT INFO

PATH=/bin:/sbin:/usr/bin
DAEMON=/opt/openerp/server/bin/openerp-server.py
NAME=openerp-server
DESC=openerp-server

# Specify the user name (Default: openerp).
USER=openerp

# Specify an alternate config file (Default: /etc/openerp-server.conf).
CONFIGFILE="/etc/openerp-server.conf"

# pidfile
PIDFILE=/var/run/$NAME.pid

# Additional options that are passed to the Daemon.
DAEMON_OPTS="-c $CONFIGFILE"

[ -x $DAEMON ] || exit 0
[ -f $CONFIGFILE ] || exit 0

checkpid() {
    [ -f $PIDFILE ] || return 1
    pid=`cat $PIDFILE`
    [ -d /proc/$pid ] && return 0
    return 1
}

case "${1}" in
        start)
                echo -n "Starting ${DESC}: "

                start-stop-daemon --start --quiet --pidfile ${PIDFILE} \
                        --chuid ${USER} --background --make-pidfile \
                        --exec ${DAEMON} -- ${DAEMON_OPTS}

                echo "${NAME}."
                ;;

        stop)
                echo -n "Stopping ${DESC}: "

                start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
                        --oknodo

                echo "${NAME}."
                ;;

        restart|force-reload)
                echo -n "Restarting ${DESC}: "

                start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
                        --oknodo

                sleep 1

                start-stop-daemon --start --quiet --pidfile ${PIDFILE} \
                        --chuid ${USER} --background --make-pidfile \
                        --exec ${DAEMON} -- ${DAEMON_OPTS}

                echo "${NAME}."
                ;;

        *)
                N=/etc/init.d/${NAME}
                echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2
                exit 1
                ;;
esac

exit 0

Tras eso cambiamos los permisos a root:

chmod 755 /etc/init.d/openerp-server
chown root: /etc/init.d/openerp-server

#Con el directorio de logs hay que hacer lo mismo
mkdir /var/log/openerp
chown openerp:root /var/log/openerp

#Y finalmente añadimos el servicio para que se inicie con el sistema:
update-rc.d openerp-server defaults

Ahora podéis probar a arrancar y ver si todo furrula: sudo /etc/init.d/openerp-server start y si la cosa va bien, en el puerto 8080 debería haber una página de prueba.

Pero claro, ahora toca el cliente web. El proceso es similar, tenéis que meterle mano a cd /etc/openerp-web.conf.

server.environment = "development"

# Some server parameters that you may want to tweak
server.socket_host = "0.0.0.0"
server.socket_port = 8080

# Sets the number of threads the server uses
server.thread_pool = 10

tools.sessions.on = True
tools.sessions.persistent = False

# Simple code profiling
server.profile_on = False
server.profile_dir = "profile"

# if this is part of a larger site, you can set the path
# to the TurboGears instance here
#server.webpath = ""

# Set to True if you are deploying your App behind a proxy
# e.g. Apache using mod_proxy
#tools.proxy.on = True

# If your proxy does not add the X-Forwarded-Host header, set
# the following to the *public* host url.
#tools.proxy.base = 'http://mydomain.com'

# logging
#log.access_file = "/var/log/openerp-web/access.log"
log.error_file = "/var/log/openerp/openerp-web-error.log"
log.access_level = "INFO"
log.error_level = "INFO"

# Set to false to disable CSRF checks
tools.csrf.on = True

# replace builtin traceback tools by cgitb
tools.log_tracebacks.on: False
tools.cgitb.on: True
# a default install can probably avoid logging those via cgitb as they're
# available in the server log
tools.cgitb.ignore=(
    openobject.errors.Concurrency,
    openobject.errors.TinyException)

# OpenERP Server
openerp.server.host = 'localhost'
openerp.server.port = '8070'
openerp.server.protocol = 'socket'
openerp.server.timeout = 450

# Web client settings
[openerp-web]
# filter dblists based on url pattern?
# NONE: No Filter
# EXACT: Exact Hostname
# UNDERSCORE: Hostname_
# BOTH: Exact Hostname or Hostname_

dblist.filter = 'NONE'

# whether to show Databases button on Login screen or not
dbbutton.visible = True

# will be applied on company logo
company.url = ''

Tras esto, de nuevo toca cambiar propietarios:

chown openerp:root /etc/openerp-web.conf
chmod 640 /etc/openerp-web.conf

Tras esto tocará automatizar el cliente web también, tocando /etc/init.d/nano openerp-web y dejando la cosa tal como en el ejemplo:

#!/bin/sh

### BEGIN INIT INFO
# Provides:             openerp-web
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Should-Start:         $network
# Should-Stop:          $network
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    OpenERP Web - the Web Client of the OpenERP
# Description:          Open ERP is a complete ERP and CRM software.
### END INIT INFO

PATH="/sbin:/bin:/usr/sbin:/usr/bin"
DAEMON="/opt/openerp/web/openerp-web.py"
NAME="openerp-web"
DESC="openerp-web"

# Specify the user name (Default: openerp).
USER=openerp

# Specify an alternate config file (Default: /etc/openerp-web.conf).
CONFIGFILE="/etc/openerp-web.conf"

# pidfile
PIDFILE=/var/run/$NAME.pid

# Additional options that are passed to the Daemon.
DAEMON_OPTS="-c $CONFIGFILE"

[ -x $DAEMON ] || exit 0
[ -f $CONFIGFILE ] || exit 0

checkpid() {
    [ -f $PIDFILE ] || return 1
    pid=`cat $PIDFILE`
    [ -d /proc/$pid ] && return 0
    return 1
}

case "${1}" in
        start)
                echo -n "Starting ${DESC}: "

                start-stop-daemon --start --quiet --pidfile ${PIDFILE} \
                        --chuid ${USER} --background --make-pidfile \
                        --exec ${DAEMON} -- ${DAEMON_OPTS}

                echo "${NAME}."
                ;;

        stop)
                echo -n "Stopping ${DESC}: "

                start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
                        --oknodo

                echo "${NAME}."
                ;;

        restart|force-reload)
                echo -n "Restarting ${DESC}: "

                start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
                        --oknodo

                sleep 1

                start-stop-daemon --start --quiet --pidfile ${PIDFILE} \
                        --chuid ${USER} --background --make-pidfile \
                        --exec ${DAEMON} -- ${DAEMON_OPTS}

                echo "${NAME}."
                ;;

        *)
                N=/etc/init.d/${NAME}
                echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2
                exit 1
                ;;
esac

exit 0

En fin, de nuevo sólo nos queda cambiar los permisos de propietario e incluir el script en el inicio, para que todo vaya como la seda:

chmod 755 /etc/init.d/openerp-web
chown root: /etc/init.d/openerp-web

update-rc.d openerp-web defaults

Y con todo esto, el servidor y el cliente web ya están listos para trastear con OpenERP en vuestro equipo.

Instalar PostgreSQL en Ubuntu / Debian / Linux Mint

PostgreSQL mola por muchos motivos: es libre (licencia BSD), es estable, puede usarse en aplicaciones comerciales, es muy escalable y tiene un elefante como logo (y todo el mundo que no es Borbón ama a los elefantes).

La instalación de PostgreSQL en tu linux (ya sea Debian, Ubuntu o Mint) es sencillita. Empezaré con Ubuntu/Mint, y tras esto, Debian.

Empezamos con el clásico:

sudo apt-get install postgresql  libpq-dev

En Debian la cosa sería prácticamente igual pero con aptitude en lugar de apt-get.

Luego toca lanzar una instancia del servidor de bases de datos y cambiar la

su -n postgres

psql -d postgres -U 

##ahora estaréis en la una instancia de Postgres, ya.
postgres=#
postgres=# alter user postgres with password 'El que toque' 
postgres=# q

Obviamente en vez de ‘El que toque» ponéis un password decente, uno que creáis seguro (nunca menos de 12 dígitos, con letras, número y símbolos)

Y tras esto sólo os queda instalar el entorno gráfico del servidor de la base de datos. Para esto basta un simple:

sudo apt-get install pgadmin3

PostgresAdmin es un cómodo y liviano entorno gráfico que os facilitará mucho la vida.

Ok ¿y en Debian? Similar y sencillito. Ya no explico los pasos, porque son los mismos, lo meto todo en un mismo bloque de texto:

aptitude install postgresql

##Cambiamos la contraseña

su postgres

psql

alter user postgres with password 'nuevopassword';

##Instalamos PostgresAdmin

aptitude install pgadmin3

Ya lo ves, clavadico en Debian.

En fin, es tarde y mañana tengo un examen de certificación de Oracle así que os dejo con esto. Estos días estoy menos activo porque he estado chapando para estas cosas y administrando y gestionando la página de WP del festival Pardiñas Rock.