Estimados todos, estimado Anthony:
Gracias por tus sugerencias. Finalmente, en principio me decidiré por
entrecomillar los campos, ya que puede ocurrir también que los valores
que luego generarán las columnas contengan espacios, por no hablar de
caracteres especiales y/o no ascii, lo que será otro cantar y que
requerirá de una implementación más cuidadosa y extensa.
Una cosa buena, por cierto, es que las tablas que crea la función
soportan, en principio, agrupar los datos por más de un campo y las
tablas resultantes carecen de valores NULL en la salida, lo que es un
verdadero quebradero de cabeza, y además puedes escoger el orden de las
columnas transpuestas. De rendimiento no va demasiado mal, entiendo que
transponer una tabla de más o menos 200K registros en otra de 40K y casi
600 columnas de destino en 12 s no está mal o por lo menos es asumible,
teniendo en cuenta que ya de entrada es algo que con otras bases de
datos no se puede hacer debido a la restricción en elnúmero de columnas
que pueden manejar.
Lo único malo es que al final tengo una función con un buen número de
parámetros, lo que no sé si es, en principio, muy operativo.
A los efectos anteriores, me ha resultado un poco desconcertante el
hecho de que al pasar parámetros a una funcion con valores por defecto(
p.e. mifuncion(par1 varchar, par2 varchar, par3 varchar default
'Mivalor', par4 int default 0), es preciso emplear una notación del tipo:
parametro := valor
en lugar del típico
parámetro=valor
Cuando se omite uno de los parámetros con valor por defecto anteriores
al que se da valor, es decir:
mifuncion('valor1','valor2',par4:=23)
Supongo que ese será el comportamiento establecido, pero apelo a vuestra
experiencia para ver si se puede hacer de otra manera.
En fin, cuando la tenga preparada y comentada como es debido, ya la
pondré en github para quien quiera emplearla.
Por cierto, y al hilo de esto, ¿las funciones, etc. desarrolladas para
PostgreSQL requieren de una licencia especial? Pensaba publicarla con
GPL3 pero no tengo claro si esto es posible.
Un saludo
Jorge Tornero
Hola Jorge si vas hacer esa funcion es por que en realidad la necesitas
y si la vas a compartir mejor para los demás usuarios, prefiero sobre
todo que sea la ultima(3) aunque si no creo que tenga ningun
inconveniente que los atributos se llamen como una palabra reservada,
creo que puedo hacer esto y no da problemas(entendí eso de lo que pusiste):
select 1 as from
Puedes usar select pg_get_keywords() para obtener las palabras reservadas.
saludos
El 1/29/2014 2:13 AM, Jorge Tornero - Listas escribió:
Estimados todos:
Soy un usuario habitual de tablas transpuestas o pivot tables, o como
prefiráis llamarlas. Comoquiera que las funciones de tablefunc
crosstab y análogas adolecen de ciertos defectillos, me he puesto
manos a la obra para crear una función, en mi caso en plpython, para
hacer su confección un poco menos tediosa (sobre todo, cuando el
producto final son tablas con decenas de columnas), ya que hay que
proveer a la función crosstab de una relación de columnas y tipo de
las mismas de la tabla resultante.
El problema es que mis datos (y los de cualquier otro que usase mi
función) generan columnas con nombre de columna de tres letras
(codigos alpha3 de FAO de especies marinas) , y es posible (como lo es
en mi caso) que aparezcan registros de la especie AND que, al ser
colocado como nombre de campo y ser palabra reservada, provoquen un
error en la función.
Mi pregunta es sobre si, desde el punto de vista de
usuarios/profesionales y sobre la usabilidad de la función, sería
preferible:
1) Modificar los campos de salida con un sufijo/prefijo (tipo _ )
2) Al definir los campos de salida emplear comillas dobles, lo que
tiene la desventaja de tener que emplearlas en las consultas
3) Emplear cualquiera de las dos soluciones sólo en el caso de que el
campo tenga tres letras o coincida con una palabra reservada (hay
listas de eso?)
Muchas gracias por vuestra ayuda.
Jorge Tornero
Instituto Español de Oceanografía
Centro Oceanográfico de Cádiz
-
Enviado a la lista de correo pgsql-es-ayuda
(pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
________________________________________________________________________________________________
III Escuela Internacional de Invierno en la UCI del 17 al 28 de febrero
del 2014. Ver www.uci.cu
