Una de las características más interesantes de 7.4 es el esquema de información, el cual describe las definiciones de una base de datos PostgreSQL según el estándar SQL. Muestra los elementos de una base de datos que se encuentran usando el esquema pg_catalog o los comandos internos (con barra invertida o backslash) en psql.

El esquema de información es la implementación del SQL Information Schema tal como se define en el capítulo 20 de ISO 9075-2:1999. Fue agregado a 7.4 por Peter Eisentraut pero no apareció en la TODO list. El esquema de información implementa parte del estándar SQL, por lo cual no refleja todas las características especiales de PostgreSQL; por ejemplo, no muestra los diferentes lenguajes en los que se pueden escribir funciones.

El esquema se instala por omisión en las bases de datos 7.4 y se llama 'information_schema'. Por omisión este esquema no está en la ruta de búsqueda, por lo que debe ser agregado a la ruta de búsqueda o accedido explícitamente. Por ejemplo,

	SET search_path TO public, information_schema;
	o
	SELECT * FROM information_schema.tables;

La siguiente tabla muestra los nombres de las vistas y tablas que existen en el information_schema. Algunas son autoexplicativas y otras son complicadas, manteniendo la definición provista por el estándar.

Cada columna en cada una de estas vistas tiene uno de los siguientes cuatro tipos:

cardinal_number	Un entero no negativo.
character_data	Una cadena de caracteres (sin especificar un largo máximo)
sql_identifier	Una cadena de caracteres. Este tipo es usado para los identificadores SQL. El tipo character_data se usa para otros tipos de datos de texto.
time_stamp	Un dominio sobre el tipo timestamp

Los datos booleanos (verdadero/falso) se representan en el esquema de información con una columna de tipo character_data que contiene YES o NO (el esquema de información se inventó antes que el estándar SQL incluyera el tipo boolean, de modo que esta convención es necesaria para mantener la compatibilidad con versiones anteriores).

La información contenida en el esquema de información puede ser rápida y apropiada, o puede ser inadecuada y excesiva. Toda la información disponible también puede ser obtenida en el esquema pg_catalog; sin embargo, el esquema de información puede ser más fácil de leer, particularmente con la expansión de la información almacenada en pg_catalog en forma de array.

El esquema de información es muy útil para los que construyen herramientas para manipular bases de datos en concordancia con el estándar SQL, pero no puede proveer información específica de PostgreSQL. Los comandos internos de psql no proveen la información específica muy fácilmente; sin embargo, no está necesariamente disponible en vistas. Tomar y traducir las consultas usadas para construir la información de los comandos internos no siempre es fácil, y es y será tema de muchas preguntas.

Como se puede ver por los beneficios y las debilidades y la ambigüedad, el uso del esquema de información estándar SQL siempre será una cosa de preferencia, tal como lo es el acceso directo a pg_catalog. Se recomienda darle una mirada cuidadosa al esquema de información.

Contribuyeron: peter_e at gmx.net, elein at varlena.com

La pregunta en cuestión era cómo crear una expresión con O exclusivo (XOR). Escribir la sentencia CASE es más bien tedioso si hay más de dos operandos involucrados.

	select case when $1 then
		(select case when $2
			then 'f'
			else (select case when $3 
				then 'f'
			...and so on...
	end

La parte simpática de este thread fue la creación rápida de un nuevo operador booleano de Peter Child. Ilustra lo sencillo que es crear un nuevo operador. Se crea la función xor(bool,bool) y se usa la cadena "~|" como operador, una opción relativamente arbitraria. El procedimiento básico para crear un operador es unir una función con un par de tipos para los argumentos izquierdo y derecho.

	CREATE FUNCTION xor(bool,bool) RETURNS bool AS '
		SELECT ($1 AND NOT $2) OR (NOT $1 AND $2);
	' LANGUAGE 'sql';

	CREATE OPERATOR ~| (PROCEDURE='xor',LEFTARG=bool,RIGHTARG=bool);

Manfred Koizar nos volvió a la vida real y al álgebra de principiantes recordándonos que <> (no igual a) en argumentos booleanos nos entrega exactamente la misma funcionalidad que el XOR deseado. Oh, por supuesto, yo ya sabía eso.

Contribuyeron: Nagib Abi Fadel nagib_postgres at yahoo.com, Pavel Stehule stehule at kix.fsv.cvut.cz, Peter Childs blue.dragon at blueyonder.co.uk, Manfred Koizar mkoi-pg at aon.at

Un volcado de una base de datos con muchas tablas causó el siguiente error:

 $ pg_dumpall >full.db
 pg_dump: WARNING:  ShmemAlloc: out of memory
 pg_dump: Attempt to lock table "vs_dfa554862ac" failed.  ERROR: 
 LockAcquire: lock table 1 is out of memory
 pg_dumpall: pg_dump failed on bandwidth, exiting

La base de datos tenía 3000 tablas, y cada tabla tiene unas 1500 filas que contienen fecha, timestamp y cantidades. El tamaño de la base de datos estaba entre 25 Gb y 9 Gb.

La recomendación fue incrementar max_locks_per_transaction en el archivo postgresql.conf. Se requiere reiniciar el servidor para que este cambio tenga efecto. Es comúnmente sabido que este error de ShmemAlloc en particular es causado por un número insuficiente en max_locks_per_transaction. Prontamente, Tom Lane se ofreció a agregar esta información al mensaje de error en 7.4, pese al estado de fijación de strings (string freeze).

El thread continuó con la discusión del razonamiento que hay tras la creación de 3000 tablas pequeñas en lugar de una grande con los índices apropiados. La decisión será reexaminada con la nueva información y la corrección para el problema de los índices crecientes.

Contribuyeron: Nick Burrett nick at dsvr.net, Joseph Shraibman jks at selectacast.net, Tom Lane tgl at sss.pgh.pa.us, Sean Chittenden sean at chittenden.org, Manfred Koizar mkoi-pg at aon.at, Greg Stark gsstark at mit.edu

Hubo muchos cambios en el archivo postgresql.conf entre 7.3 y 7.4. Aunque muchos cambios están documentados en el documento Annotated Postgresql.conf de Shridar y Josh, es bueno examinar las diferencias específicas ahora, justo antes del lanzamiento de la versión 7.4. Esta información puede ser usada para actualizar su archivo postgresql.conf para 7.4.

Cambios en Valores por Omisión El cambio a datestyle se relaciona con el cambio en la entrada de fechas, y el resto de aquí se relaciona con muchas y largas discusiones en pgsql-hackers y pgsql-performance.

Los parámetros para Desarrolladores fueron eliminados. La mayoría de ellos requiere cambios durante la compilación para ser útiles.

Cambios de Nombre Algunas variables cambiaron de nombre. Ninguno de los valores por omisión fueron cambiados.

Cambios en Características, Misceláneos Las siguientes opciones fueron agregadas (o eliminadas) según los cambios en características o nuevos desarrollos.

Contribuyeron: elein at varlena.com