Re: Error en funcion SOLUCIONADO

Excerpts from Jaime Casanova's message of mié oct 27 10:39:40 -0300 2010:

> te contesto si me contestas una pregunta simple. que tipo de dato
> corresponde al valor siguiente: 5

> un numero sin cast explicito no tiene un contexto claro asi que
> postgres asume integer

De hecho es todo un tema saber qué tipo tiene un determinado valor. Si
tú decides que un número chico debería considerarse smallint, entonces
¿qué pasa con una operación como 256 * 256? Una alternativa sería
decidir que tira error de overflow (pero seguro que más de alguien
reclama). Otra alternativa sería determinar que el operador int2 * int2
retorna tipo int4, lo cual ocasionaba otra inconsistencia que no
recuerdo.

Pero en realidad el gran escollo es el tema de los tipos preferidos
dentro de cada categoría de tipos. Actualmente cada categoría tiene un
tipo preferido (typpreferred creo que se llama la columna en pg_type),
que es un boolean. Para poder hacer algo sensato con las conversiones
de tipo habría que cambiar esa clasificación en una escala: o sea int2
sería "más" preferido que int4, el cual sería a su vez más preferido que
int8. Así, puede haber casts de int2 a int4 y a int8, y el escalafón de
preferencia podría determinar a qué se va haciendo "promoción" a medida
que es necesario. Pero nadie ha explorado totalmente las posibilidades
y problemas que traería hacer un cambio de este tipo en el sistema de
tipos. (En Command Prompt tenemos un cliente que quería que
arregláramos precisamente este problema, pero hasta el momento no he
encontrado la energía para ponerme en ello).

Hay que agregar que el sistema de tipos de Postgres es de los más
complejos que existen en las implementaciones de tipado fuerte, dando
cabida a extensibilidad dentro del sistema, es decir, que el usuario
puede crear nuevos tipos e influir en los algoritmos de selección, y que
el resultado siga siendo coherente (si bien no siempre es 100%
satisfactorio para todo el mundo).

Finalmente quisiera acotar que los tipos más chicos no necesariamente
permiten ahorrar espacio de almacenamiento. Por ej. considera la
siguiente tabla:

a int2
b int4

Dado que el tipo int4 tiene alineamiento de 4 bytes, queda un "hueco"
entre las columnas a y b de 2 bytes, por lo que sigue ocupando 8 bytes.
Dadas todas las complicaciones que implica usar tipo int2, sale más
fácil usar int4 para ambas columna, y usas el mismo espacio de
almacenamiento sin ninguno de los inconvenientes.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support