PostgreSQL no es una base de datos apropiada para usar en medios de sólo lectura. Por ejemplo, no funcionaría distribuir una aplicación de diccionario de sólo lectura en un CD.

PostgreSQL trata de escribir algunos archivos durante la operación, incluso si las consultas sólo son SELECT.

• archivo de registro -- Esto puede ser enviado a /dev/null
• pgstat.stat -- Las estadísticas se pueden desactivar
• pg_clog -- Usado para mantener los estados de las transacciones.

Algunas bases de datos alternativas pueden ser mejores para esta clase de distribución de aplicaciones. Se sugirió:

• Dan Bernstein's Constant Database
  • Basado en hash. No hay ordenamiento o calces parciales
  • No hay SQL
  • Las licencias son confusas
• Firebird Incrustado
  • Software propietario
• archivos ISAM
• Varias bases de datos OO

Mientras PostgreSQL requiera escribir para las transacciones de sólo lectura, seguirá siendo una solución inviable para una aplicación con una base de datos en CD.

Contribuyeron: Joost Kremers joostkremers at fastmail.fm, Bruce Momjian pgman at candle.pha.pa.us, Ang Chin Han angch at bytecraft.com.my, Christopher Browne cbbrowne at acm.org, Jacob Hanson jacobhanson at firsthealth.com, Ron Johnson ron.l.johnson at cox.net, Dann Corbit DCorbit at connx.com

Hay dos maneras básicas de usar valores por enumeración en PostgreSQL. La primera es con una restricción CHECK en las columnas involucradas, y la segunda con una tabla de búsqueda.

Para usar una restricción CHECK, definiría la columna al momento de definir la tabla, como:

	CREATE TABLE foo (
		...
		enum	text	CHECK ( enum in ('a','b','c')),
		...
	);

El uso de una tabla de búsqueda aprovecha la integridad referencial y permite actualizaciones fáciles al conjunto enumerado.

	CREATE TABLE enum_abc (val text NOT NULL PRIMARY KEY);
	INSERT INTO enum_abc values ('a');
	INSERT INTO enum_abc values ('b');
	INSERT INTO enum_abc values ('c');
	
	CREATE TABLE foo (
		...
		enum text REFERENCES enum_abc (val),
		...
	);

La simplicidad de las tablas de búsqueda es irresistible cuando el conjunto de datos enumerados no está completamente fijo. Esto creo que es cierto aún con la capacidad de usar ALTER DOMAIN CONSTRAINTS en 7.4.

Contribuyeron: Bruno BAGUETTE pgsql-ml at baguette.net, Shridhar Daithankar shridhar_daithankar at persistent.co.in, Vivek Khera khera at kcilink.com, Dennis Gearon gearond at fireserve.net, Ron Johnson ron.l.johnson at cox.net, Bruce Momjian pgman at candle.pha.pa.us, scott.marlowe scott.marlowe at ihs.com, Joseph Hepburne Healy j.healy at ugrad.unimelb.edu.au

Una de las primeras cosas que hacer cuando una consulta es lenta es verificar que los tipos de datos en las expresiones son compatibles. Por ejemplo, cuando se verifica un número constante contra un bigint, se sugiere que convierta el número explícitamente a bigint. Esta idea fue desarrollada en la Edición #36.

Una consulta en la lista HACKERS hizo notar que las llaves foráneas pueden tener el mismo problema.

	CREATE TABLE a (b int4 UNIQUE);
	CREATE TABLE c (d int8 REFERENCES a (b));

Esta llave foránea funcionaría más rápidamente si a.b fuera del mismo tipo que c.d.

La discusión en HACKERS se centró en el envío de un mensaje NOTICE o WARNING cuando se crea una FOREIGN KEY de distinto tipo. Este mensaje podría ser muy útil. Sin embargo, es muy importante ponerle atención a sus relaciones e impedir que suceda. Aunque la llave foránea de tipo distinto funcionará tal como se espera, no será tan rápida o limpia. Por definición las llaves foráneas deben ser del mismo tipo.

Contribuyeron: Neil Conway neilc at samurai.com, Tom Lane tgl at sss.pgh.pa.us, Peter Eisentraut peter_e at gmx.net, Bruce Momjian pgman at candle.pha.pa.us, Robert Treat xzilla at users.sourceforge.net

No hay diferencia de comportamiento entre varchar y text. La diferencia entre varchar(n) y text está en que el largo del valor para varchar está limitado a n. El almacenamiento para ambos (los tres?) tipos es el mismo, aunque cada uno tiene su propio identificador único de tipo.

varchar[(n)] y text existen porque en el Postgres original text existió primero. Luego se agregó varchar[(n)] para conformar con el estándar SQL. No hay planes para eliminar un tipo en favor del otro o consolidar sus identificadores únicos de tipo. Dado que comparten la misma representación interna, es improbable que suceda.

Las razones para usar varchar[(n)] son:

• Manejo en ODBC de varchar es mejor que text.
• Restringir los límites de largo de los datos.
• Portabilidad entre bases de datos.

• Menos conversiones de tipo, implícitas o explícitas (más rápido)
• Es el tipo de texto nativo
• No hay necesidad de restringir los límites de largo

Consistencia en la definición de campos de texto en la definición de su base de datos ayudará a acelerar sus consultas. Se sugiere que use consistentemente text para aplicaciones no-ODBC.

Contribuyeron: Curtis Hawthorne mr_person at mrperson.org, Dmitry Tkach dmitry at openratings.com, scott.marlowe scott.marlowe at ihs.com, Andrew Ayers aayers at eldocomp.com, Tom Lane tgl at sss.pgh.pa.us, Greg Stark gsstark at mit.edu

Un identificador es el nombre de un objeto: el nombre de una tabla, el nombre de un esquema, un nombre de columna, un nombre de tipo, etc. Los identificadores tienen reglas especiales con respecto a las mayúsculas y minúsculas.

Por omisión, PostgreSQL convierte todos los identificadores de manera que la mayusculización es ignorada. Para usar identificadores sensibles a mayúsculas, cada vez que se refiera a ellos use comillas dobles.

    SELECT foo, FOo, Foo, fOO          -- todos convertidos a "foo"
    SELECT "foo", "FOo", "Foo", "fOO"  -- son todos diferentes

	SELECT * from "MySchema"."MyTable";

Los usuarios actuales y antiguos de Oracle tienden a escribir los nombres de tabla en mayúscula por costumbre. Esto no presenta problemas hasta que se usa una aplicación como PostgreSQL Manager Pro que pone todos los identificadores entre comillas. Después de crear todas las tablas y otros como "UPPERTABLE", todas las referencias de ahí en adelante deben ser "UPPERTABLE".

PostgreSQL no es conforme al estándar en su método de conversión. La mayoría de las bases de datos convierten a mayúsculas, mientras que PostgreSQL convierte a minúsculas. Esto significa que en otra base de datos, una tabla definida como "UPPER" puede ser referida más adelante como upper. En PostgreSQL es lo contrario. Una tabla definida como "upper" puede ser referida más adelante como UPPER. Es improbable que esto cambie.

La manera más común de tratar con identificadores es nunca ponerlos entre comillas, y permitir que se conviertan a minúsculas. Si se ve obligado a tener un identificador sensible a mayúsculas, póngalo entre comillas cuando quiera usarlo.

Contribuyeron: Terence Chang TChang at nqueue.com, Arguile arguile at lucentstudios.com, Stephan Szabo sszabo at megazone.bigpanda.com, Thomas Kellerer spam_eater at gmx.net, Reuben D. Budiardja techlist at voyager.phys.utk.edu, Andrew Sullivan andrew at libertyrms.info, Ron Johnson ron.l.johnson at cox.net, Tom Lane tgl at sss.pgh.pa.us

PgSQL, Inc. está haciendo una nueva tirada de camisetas de PostgreSQL y necesita un buen slogan para esta imagen. Tanto el slogan como la imagen irán en la parte de atrás.

La idea actual es "Of the people, For the people", en referencia a la gente que guía al elefante desde el suelo, el cual acarrea a la gente sobre su espalda ...

Creo que podemos encontrar una línea más pegajosa que se grabe mejor en la mente. ¡Envíe sus sugerencias aquí!

Contribuyeron: Marc G. Fournier scrappy at hub.org