Hay un nuevo enlace en PostgreSQL General Bits para lectores hispanoparlantes. Contiene los artículos de General Bits traducidos por Álvaro Herrera. ¡Bienvenidos todos los lectores hispanoparlantes! Estoy segura que disfrutarán el trabajo de Álvaro.

Puede leer la primera edición en castellano aquí. A la izquierda hay un enlace a las Ediciones en Castellano donde se pueden ver las ediciones traducidas.

Contribuyeron: elein at varlena.com

Se ha creado una lista de correo en francés (pgsql-fr-generale), y además hay un sitio web http://pgsql-fr.tuxfamily.org/ dedicado principalmente a la traducción de PostgreSQL al francés.

La lista de correo pronto será agregada a PostgreSQL Mailing Lists y archivada.

Contribuyeron: Francois Suter dba at paragraf.ch

Es posible ejecutar consultas dinámicas en plpgsql construyendo la cadena de la consulta y luego ejecutándola en la función. Las consultas dinámicas son particularmente útiles cuando se quiere pasar un nombre de tabla o un nombre de columna como parámetro. Sin embargo, algunos detalles deben ser tenidos en cuenta.

En plpgsql, puede ejecutar sentencias SELECT dinámicas y manejar el resultado sólo a través de un FOR LOOP. Esto es muy útil para retornar SETs y SETs de RECORDS. A veces se requiere poner un SELECT de un solo elemento en el ciclo; no es posible asignar o usar SELECT INTO. Pero sí se pueden usar sentencias INSERT, UPDATE y DELETE y sentencias DDL (Data Definition Language: CREATE, ALTER, etc).

Lo otro que hay que tener presente al construir consultas dinámicas en plpgsql es la omnipresente comilla simple. Recuerde que debe duplicar las comillas simples en el cuerpo de la función, y si usa comillas simples en la consulta dinámica, debe cuadruplicarlas. Use los operadores de concatenación de texto '||' para unir texto y valores de variables en la cadena de la consulta.

Este ejemplo toma un nombre de tabla y un nombre de columna. Luego aplica quita los espacios en blanco al principio y al final del campo (trim), y actualiza la columna especificada en todos los registros de la tabla.

	create or replace function trimtablecol(text, text )
	returns void
	as '
	DECLARE
	qry text;
	tab alias for $1;
	col alias for $2;
	BEGIN
	   qry := ''update '' || tab || '' set '' || col || ''=trim('' || col || '');'';
	   EXECUTE qry;
	   RETURN;
	END;

	' language 'plpgsql';

Usando un FOR LOOP en el siguiente ejemplo, la cadena de la consulta es construida al momento de la ejecución. Debido a que el argumento es un campo de texto, necesita las comillas adicionales.

	create or replace function fortythree(text)
	returns float
	as '
	DECLARE
	   v_tmp RECORD;
	   ret_avg_price float;
	   myid alias for $1;
	BEGIN
	   FOR v_tmp IN EXECUTE ''SELECT avg(price) AS avg_price
	                     FROM fortythree
	                     WHERE id = '''''' || myid || ''''''
	   LOOP
	
	   ret_avg_price := v_tmp.avg_price;
	
	   END LOOP;
	   RETURN ret_avg_price;
	END;
	' language 'plpgsql';

Tenga en cuenta que también puede ejecutar consultas dinámicas en plperl, tcl y plpython, y en algunos casos la construcción de la cadena de la consulta es más simple.

Contribuyeron: elein at varlena.com

Este hilo de discusión cubrió varios temas interesantes:

• uso de 7.4Beta en producción,
• problemas que aparecen al comparar columnas int8 con constantes enteras,
• requerimientos e implementación de actualizaciones a los catálogos de sistema, y
• si el incremento de tamaño de página por omisión afectaría el tamaño límite de un registro.

La pregunta es si actualizar o no actualizar. Aquellos que tienen sus propios productos que lanzar quieren saber si 7.4 es suficientemente seguro para uso en producción, porque será más sencillo usar 7.4 que usar 7.3 y actualizar luego. De todos los 'beta testers', sólo uno indicó que tiene un sistema en producción: Marc Fournier, que sirve los archivos de las listas de correo de PostgreSQL.org usando 7.4Beta2.

Por otra parte, se hizo notar que para resolver los problemas de comparaciones de columnas int8 con constantes enteras, podría requerirse un ciclo de respaldo-recuperación antes de lanzar la versión final de 7.4. Esto llevó a que mucha gente hiciera notar lo mucho que molestan los requisitos de respaldo y recuperación.

Un ciclo de respaldo y recuperación se requiere, en general, cuando se hacen cambios a los catálogos del sistema. Algunas personas hicieron notar que, especialmente con bases de datos muy grandes, un ciclo de respaldo y recuperación es prohibitivo y a menudo provoca retrasos en las actualizaciones, las cuales podrían ser muy útiles. Encontrar un momento y un lugar apropiados para hacer un respaldo de un par de terabytes es evidentemente difícil.

A veces, es posible actualizaciones usando scripts en la base de datos, evitando la necesidad de respaldo-recuperación. En este momento, Tom indicó que cada cambio requeriría un examen para encontrar los requerimientos de actualización, y deberían escribirse scripts de actualización. Esto funcionaba en Informix (cuando yo [elein] trabajé ahí), pero es difícil de exigir en nuestro medio. Además, los scripts de actualización tienen que ser perfectos, y nuestros desarrolladores pagados son pocos, así como lo es la gente que puede hacer desarrollo en el corazón de PostgreSQL. En realidad, es una buena idea y si tuviéramos una persona dedicada constantemente a esto sería muy bueno.

Esta discusión de los scripts de actualización siguió más allá del tiempo de publicación de General Bits y ha sido discutida con anterioridad en pgsql-hackers. Espere más consideraciones y posibles cambios en el futuro.

Otro cambio que requeriría un respaldo y recuperación es el tamaño de página por omisión de PostgreSQL. Una razón para incrementarlo es que se cree que podría permitir manejar mejor registros muy grandes. Otra razón más importante es que puede aumentar el rendimiento en algunas máquinas.

Aunque el aumento de tamaño de página puede estar disponible después de 7.4 en forma de parche al código, hay varias cosas a tener en cuenta. Primero, se requieren más pruebas en más plataformas antes de que un cambio como éste sea seguro. Segundo, un respaldo hecho en una máquina con un tamaño de página mayor puede no ser recuperable en una máquina con el tamaño de página por omisión. Esto es una advertencia a la gente que considere cambiar el tamaño de página. Por último, se hizo notar el oscuro tópico del tamaño de registro.

El número máximo de columnas que pueden haber en un registro es alrededor de 1600. Pero este número es una pista falsa, porque no es el verdadero límite. Dependiendo de los tipos de los datos del registro, es muy probable que encuentre un límite con menos columnas. La limitación verdadera es si el registro cabrá en el bloque (página). En este momento se hicieron comentarios sobre el código :-) Sin embargo, el tamaño máximo de la representación de un registro es del tamaño de una página. El tamaño incluye encabezados de tuplas y columnas de varios tipos, estén almacenadas en TOAST o no.

Esto sólo es calculable tabla por tabla, y dentro de eso, columna por columna. Se especuló que se podrían tener 1600 columnas de tipo int2, si se le llegaba a encontrar alguna utilidad. Y Tom Lane indicó que "si todas tus columnas son de un tipo TOASTable, y las tienes todas en TOAST, entonces como los punteros de TOAST son de 20 bytes cada uno, con un tamaño de bloque de 8kB el número máximo usable de columnas está cerca de las 400".

Las conversaciones de este estilo, aunque no se fomentan demasiado, tienen información variada sobre las cosas que está haciendo la gente. Ahora sabemos que el archivo de las listas de postgresql.org está en 7.4, que hay un problema con las comparaciones entre int8 y constantes enteras, que hay razones para preferir actualizaciones a respaldo-recuperación, y se nos recuerda que el tamaño máximo de un registro está relacionado con el tamaño del bloque y que no es fijo.

Contribuyeron: Andrew Rawnsley ronz at ravensfield.com, Marc G. Fournier scrappy at postgresql.org, Vivek Khera khera at kcilink.com, scott.marlowe scott.marlowe at ihs.com, Tom Lane tgl at sss.pgh.pa.us, Manfred Koizar mkoi-pg at aon.at, Ron Johnson ron.l.johnson at cox.net, Nigel J. Andrews nandrews at investsystems.co.uk, Dennis Gearon gearond at fireserve.net, Kaare Rasmussen kar at kakidata.dk, Joshua D. Drake jd at commandprompt.com, Doug McNaught doug at mcnaught.org, Alvaro Herrera alvherre at dcc.uchile.cl, Lamar Owen lowen at pari.edu, Sean Chittenden sean at chittenden.org, Bruce Momjian pgman at candle.pha.pa.us

Dadas sólo horas y no horas y fechas, es posible calcular diferencias de tiempo con precisión. Esta función, proporcionada por Mattias Kregert, hace precisamente eso. ¿Pero puede encontrar el error?

	SELECT starttime, stoptime, 
	   (CASE WHEN stoptime-starttime <= 0
	    THEN stoptime-starttime 
	    ELSE stoptime-starttime+'24 hours' END) as timediff 
	FROM mytable;

Cuando esta función es ejecutada en dos bases de datos con diferentes configuraciones locales, la comparación WHEN es distinta. Asumiendo que stoptime y starttime son de tipo time, entonces se está comparando el resultado, de tipo interval, con 0. Ocurre que en la configuración local C funciona correctamente. Sin embargo, para otra configuración local, la condición falla.

La condición correcta para comparar debió ser:

	stoptime - starttime <= '0 minutes'

Contribuyeron: Bjørn T Johansen btj at havleik.no, Andrew L. Gould algould at datawok.com, Mattias Kregert mattias at kregert.se, Nigel J. Andrews nandrews at investsystems.co.uk, Tom Lane tgl at sss.pgh.pa.us, Adam Kavan akavan at cox.net

Para conocer las noticias más recientes sobre el estado del port nativo a Win32 de PostgreSQL, vea la información escrita por Bruce Momjian en http://momjian.postgresql.org/main/writings/pgsql/win32.html

Si puede ayudar con cualquiera de los asuntos por hacer, únase a la lista de correo de desarrollo en: pgsql-hackers-win32-request@postgresql.org

Contribuyeron: elein at varlena.com