Re: Problemas al igualar?...

OK,
me ha quedado claro, se que para eso existen limitancias y hay que estar
dentro de los macos que contiene el DBMS, pero quiza si puediera haber una
idea en que se pueda mejorar un poco ese tipo de inconvenientes, claro
tambien entiendo que puedo estar actualizando cualquier cosa, pero que eso
quede a criterio de programador y no en base de golpe y porraso a traves de
errores. yo apoyo 100% postgres pienso que es el mejor motor de base de
datos que existe guardando proporciones obviamente, pero si puedo ayudar con
un grano de arena haciendo una pregunta contructiva lo hare sin problemas,
respeto y tengo conciente que el fundamento que me da Juan Martinez es super
claro y logico y se basa en la estructura logica del motor, pero postgres
podria generar niveles de inteligencia en este tipo de casos por lo menos en
las comparaciones del mismo tipo con distinto largo puntualmente, en que
simplemnete no retorne nada.

Gracias por las respuestas

--

Patricio Cifuentes Ithal
Ingeniero en Informática

Desarrollo Tecnológico
SIIGSA
(56-2) 204 60 22
----- Original Message -----
From: "Juan Martínez" <jeugenio(at)umcervantes(dot)cl>
To: "Patricio Cifuentes Ithal" <pcifuentes(at)siigsa(dot)cl>
Cc: "postgresql-es" <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Thursday, September 28, 2006 2:30 PM
Subject: Re: [pgsql-es-ayuda] Problemas al igualar?...

> Patricio Cifuentes Ithal escribió:
> > no se si sera un bugs, ya que me causa un poco de ilogica este problema.
> > tengo una query de un update el cual es el siguiente
> >
> > Update usuario SET usuario_num = 1 WHERE usuario_fol = 600001;
>
> Ok.
>
> > bueno el tema del problema no esta dentro del set, si no que en el WHERE
el campo usuario_fol es un int2
>
> Entonces eso que pones ahi esta mal. Un INT2 esta entre [-32768|32767] y
> el valor 600001 ciertamente esta fuera de rango.
>
> > y me da un error de que ese campo es muy pequeño para la cifra en la
cual estoy igualando
>
> Obvio.
>
> > claro el mensaje de error es super logico, pero ese error corresponde?.
>
> Mmmm...que crees tu?
>
> > Pienso yo que esos errores deben estar y salen y estan cuando trato de
insertar o actualizar un campo con un valor mas grande que el que soporta,
pero en una igualacion dentro de un WHERE realmente es un opco tonto, creo?
>
> No pues.
>
> Imaginate que el ORDBMS termina actualizando cualquier tupla. Lindo no?
>
> Por algo existen los tipos de datos. No tan solo para delimitar o mas
> bien dicho, definir por definir lo que un atributo en la tabla va a
> contener.
>
> Generalmente, cuando uno diseña una BD, todo debiera ser de tipo
> numerico, excepto lo estrictamente necesario. Por suerte postgres tiene
> varias opciones de tipos numericos.
>
> Yo incluso a veces, uso a proposito determinados tipos de numericos para
> hacer integridad de datos. Si un determinado campo se que no debiera
> albergar valores superiores a 10000 aprox., por ejemplo, voy a usar un
> INT2, aunque podria usar INT4 o INT8 y con CHECK hago la limitacion.
> Hasta donde se el rendimiendo no varia mucho entre usar cualquiera de
> los INT, pero sirve como una manera muy rudimentaria de hacer
> integridad...muy util por lo demas.
>
> Entonces obvio que postgres se va a molestar si le estas tratando de
> pasar un valor que esta fuera de rango...
>
> > si hay alguna respuesta logica o una estructura o esquema que
corresponda por favor envienmela.
>
> Mira la documentacion.
>
> --
> Juan Martinez G.
> Departamento de Informatica
> Universidad Miguel de Cervantes
>
> --
> Este mensaje ha sido analizado por MailScanner
> en busca de virus y otros contenidos peligrosos,
> y se considera que está limpio.
>
> www.siigsa.cl

--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

www.siigsa.cl