Re: compatibiliad 8.2.4 con 8.3.1

El día 19 de junio de 2008 9:32, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> escribió:
> Marcos Saldivar escribió:
>> El día 19 de junio de 2008 6:30, Juan Carlos Barranco de Paz
>> <jcb(at)greccosoft(dot)es> escribió:
>
>> > select c312frec.proveedor from c312frec
>> > where c312frec.tipo_cif <> 4
>
>> > ERROR: el operador no existe: character <> integer
>> > Estado SQL:42883
>
>> no es un bug, encontraras mas detalles en los históricos de la lista,
>> pero por lo mismo que se
>> ha escrito en esta lista yo entendí que fue una decisión del Sr.
>> Postgres es el evitar que los programadores no hagan un cast explicito
>> de los datos cuando estos son comparados. espero haber entendido bien
>> :-)
>
> Más o menos. La parte de que es un cambio deliberado es cierta. La
> parte de que es para "evitar que los programadores hagan tal cosa" no es
> cierta (o quizás no entendí lo que estás diciendo). El razonamiento que
> se usó para hacer este cambio es que los casts implícitos que existían
> anteriormente causaban problemas indeseables, oscuros, difíciles de
> detectar y difíciles de depurar, y se presentaban sobre todo en
> situaciones complejas donde no era obvio cuál era el problema. Se
> supone que luego del cambio esos problemas desaparecieron.
>
> Como consecuencia de ese cambio, muchas operaciones que antes se
> resolvían en forma implícita ahora requieren casts explícitos, lo cual
> es una molestia para los usuarios, pero necesaria (un "mal menor").

eso quise decir, igualito ja ja ja.

en realidad a mi me más parece extraño querer comparar un character
varying(1) con un integer....

saludos