Solución:
En PostgreSQL 9.1 hay una forma más sencilla
http://www.postgresql.org/message-id/[email protected]
CREATE TABLE foog(a varchar(10));
ALTER TABLE foog ALTER COLUMN a TYPE varchar(30);
postgres=# d foog
Table "public.foog"
Column | Type | Modifiers
--------+-----------------------+-----------
a | character varying(30) |
Hay una descripción de cómo hacer esto en Cambiar el tamaño de una columna en una tabla de PostgreSQL sin cambiar los datos. Tienes que piratear los datos del catálogo de la base de datos. La única forma de hacer esto oficialmente es con ALTER TABLE, y como ha notado, el cambio bloqueará y reescribirá toda la tabla mientras se está ejecutando.
Asegúrese de leer la sección Tipos de caracteres de los documentos antes de cambiar esto. Todo tipo de casos extraños a tener en cuenta aquí. La verificación de la longitud se realiza cuando los valores se almacenan en las filas. Si piratea un límite inferior allí, eso no reducirá en absoluto el tamaño de los valores existentes. Sería aconsejable escanear toda la tabla en busca de filas en las que la longitud del campo sea> 40 caracteres después de realizar el cambio. Deberá averiguar cómo truncarlos manualmente, por lo que ha vuelto a algunos bloqueos solo en los de gran tamaño, porque si alguien intenta actualizar algo en esa fila, lo rechazará como demasiado grande ahora, en el punto va a almacenar la nueva versión de la fila. Se produce hilaridad para el usuario.
VARCHAR es un tipo terrible que existe en PostgreSQL solo para cumplir con su terrible parte asociada del estándar SQL. Si no le importa la compatibilidad con múltiples bases de datos, considere almacenar sus datos como TEXTO y agregue una restricción para limitar su longitud. Las restricciones que puede cambiar sin este problema de bloqueo / reescritura de la tabla, y pueden hacer más verificación de integridad que solo la verificación de longitud débil.
Ok, probablemente llego tarde a la fiesta, PERO …
¡NO HAY NECESIDAD DE CAMBIAR EL TAMAÑO DE LA COLUMNA EN SU ESTUCHE!
Postgres, a diferencia de otras bases de datos, es lo suficientemente inteligente como para usar solo el espacio suficiente para ajustar la cadena (incluso usando compresión para cadenas más largas), por lo que incluso si su columna se declara como VARCHAR (255), si almacena cadenas de 40 caracteres en la columna, el uso de espacio será de 40 bytes + 1 byte de sobrecarga.
El requisito de almacenamiento para una cadena corta (hasta 126 bytes) es 1 byte más la cadena real, que incluye el espacio de relleno en el caso de carácter. Las cadenas más largas tienen 4 bytes de sobrecarga en lugar de 1. El sistema comprime las cadenas largas automáticamente, por lo que el requisito físico en el disco puede ser menor. Los valores muy largos también se almacenan en tablas de fondo para que no interfieran con el acceso rápido a valores de columna más cortos.
(http://www.postgresql.org/docs/9.0/interactive/datatype-character.html)
La especificación de tamaño en VARCHAR solo se usa para verificar el tamaño de los valores que se insertan, no afecta la distribución del disco. De hecho, los campos VARCHAR y TEXT se almacenan de la misma forma en Postgres.