Re: Sugerencia de implementación

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(at)postgresql(dot)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