Re: Error en funcion SOLUCIONADO

Alvaro, muy buena explicación acerca de los tipos, pero disculpen mi
insistencia el porque en un insert normal esta situación no se
produce, pero en una función si se dá éste problema

Saludos cordiales

Mario Soto

El 27/10/10, Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
> 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
>