Re: Posible bug?

Comprendo. Pero me cuesta interpretar la relación entre ambas tablas
más allá del where...
Al margen, no conozco suficientemente el estandard SQL como para poder
debatir al respecto, solo que me llamó la atención que no protestara
el parser :D
Gracias por los comentarios.

Ricardo: creo que precisamente el parser está para avisarnos de los
despistes no para solucionarlos según su criterio.

El día 6 de enero de 2010 16:34, Ricardo Conde
<ricardocondef(at)gmail(dot)com> escribió:
> Hola Jose Luis y demás . Este 'problema' me lo tenfo encontrado yo también
> en situaciones similares y creo que no da error debido a que la base de
> datos optimiza internamente la consulta antes de ejecutarla y 'se da cuenta'
> de que utilizas un campo que no esta en 'rubro' pero si que esta en
> 'valores' que es otra tabla que estas usando en la misma consulta , en
> consecuencia  el sistema optimizador supone que es un despiste tuyo y añade
> la tabla valores a tu subconsulta, es como si hubieses hecho .....SELECT
> descripcion FROM test.rubros,test.valores WHERE....
>
> Realmente es lamentable que ocurra esto pues induce a realizar consultas que
> para mi gusto son 'mal formadas' , pues realmente en la subconsulta no
> existe el campo descripcion y sin embargo es como si el sistema 'saliera
> fuera' de la subconsulta a cogerlo de la tabla valores.
> Un saludo
>
> El 6 de enero de 2010 17:07, Jose Luis Balle <joseluisballe(at)gmail(dot)com>
> escribió:
>>
>> Hola lista,
>> acabo de toparme con una situación que me llamó la atención, no si
>> postgresql se está comportando como debiera por lo que les expongo
>> para ver si alguien puede replicar esta situacion.
>> Una sentencia que a mi modo de parecer debería devolver un error de
>> SQL debido a la inexistencia de una columna en una subconsulta, corre
>> perfectamente tomando la columna de la consulta principal.
>>
>> -- Dado el siguiente esquema:
>>
>> CREATE SCHEMA test;
>>
>> CREATE TABLE test.rubros(
>>  id character varying(3) NOT NULL,
>>  rubro character varying(35),
>>  CONSTRAINT rubros_pkey PRIMARY KEY (id)
>> )
>> WITH (OIDS=FALSE);
>>
>> INSERT INTO test.rubros VALUES ('1', 'Rubro 1');
>> INSERT INTO test.rubros VALUES ('1.1', 'Rubro 11');
>> INSERT INTO test.rubros VALUES ('2', 'Rubro 2');
>> INSERT INTO test.rubros VALUES ('2.1', 'Rubro 21');
>>
>> CREATE TABLE test.valores(
>>  id serial,
>>  rubroid character varying(3),
>>  descripcion character varying(30),
>>  monto float,
>>  CONSTRAINT valores_pkey PRIMARY KEY (id)
>> )
>> WITH (OIDS=FALSE);
>>
>> INSERT INTO test.valores (rubroid,descripcion, monto) VALUES
>> ('1.1','JAMON',100);
>> INSERT INTO test.valores (rubroid,descripcion, monto) VALUES
>> ('1.1','PALETA',200);
>> INSERT INTO test.valores (rubroid,descripcion, monto) VALUES
>> ('2.1','PEBETE',10);
>> INSERT INTO test.valores (rubroid,descripcion, monto) VALUES
>> ('2.1','GALLETA',20);
>>
>> --la siguente consulta debería devolver un error ya que la tabla
>> test.rubro no tiene una columna descripcion. Sin embargo corre
>> perfectamente tomando los valores de la columna descripcion de la
>> tabla test.valores.
>>
>> SELECT (SELECT descripcion FROM test.rubros WHERE
>> rubros.id=substr(valores.rubroid,1,1)) as rubro, *
>> FROM test.valores;
>>
>> --devuelve
>> "rubro";"id";"rubroid";"descripcion";"monto"
>> "JAMON";1;"1.1";"JAMON";100
>> "PALETA";2;"1.1";"PALETA";200
>> "PEBETE";3;"2.1";"PEBETE";10
>> "GALLETA";4;"2.1";"GALLETA";20
>>
>> --
>>
>> Espero comentarios, se que debería haber utilizado el alias de
>> test.rubros en la subconsulta y utilizo la subconsulta para obtener el
>> rubro padre de cada fila. Podria usar un join o un where si, pero me
>> salió así y me encontré con este problema.
>> Saludos.
>>
>> --
>> "La pregunta no debería ser ¿Por qué Dios permite esto?, si no ¿Por
>> qué Dios permite que yo permita esto?"
>> --
>> TIP 7: no olvides aumentar la configuración del "free space map"
>
>
>
> --
> Esta mensaxe pode conter información privilexiada e/ou confidencial. Se
> Vostede non é o destinatario a quen se dirixe ou o responsable de facerllo
> chegar, non está autorizado para utilizar información contida nela, nin
> copiala, entregala ou imprimila. Por favor, destrúa esta mensaxe e comunique
> ao remitente que o enderezo empregado é erróneo.
>
> Por favor, avísenos de inmediato se Vostede ou a súa empresa non desexa que
> lle enviemos correos electrónicos.
>
> Calquera opinión, conclusión ou outra información vertida nesta mensaxe, non
> relacionada coas actividades oficiais da nosa firma, deberá considerarse
> como nunca proporcionada ou aprobada pola mesma.
>

--
"La pregunta no debería ser ¿Por qué Dios permite esto?, si no ¿Por
qué Dios permite que yo permita esto?"