El 03/05/2013 17:44, Alvaro Herrera escribió:
Oswaldo escribió:
El 03/05/2013 16:40, Martín Marqués escribió:
No. Con ese UPDATE, el valor debe ser NULL.
Exacto el update inserta un null, pero la columna esta definida como
tipo 't_dom' el cual no debe admitir nulos. Si en vez de ese update
El día 3 de mayo de 2013 11:57, Oswaldo escribió:
> El 03/05/2013 16:40, Martín Marqués escribió:
>
>> El día 3 de mayo de 2013 08:43, Oswaldo escribió:
>>>
>>> Hola,
>>>
>>> Creo que he detectado un bug, pero antes de reportarlo os agradecería
>>> comprobaseis si la demostración es correcta y si
El 03/05/2013 17:12, Jaime Casanova escribió:
2013/5/3 Alvaro Herrera :
Oswaldo escribió:
En el resultado final la columna 'dom' tiene un valor NULL cuando
según las reglas definidas esto no deberia ser posible y se deberia
haber producido una excepción.
Hola, no tengo claro que esto sea un
Oswaldo escribió:
> El 03/05/2013 16:40, Martín Marqués escribió:
> >No. Con ese UPDATE, el valor debe ser NULL.
>
> Exacto el update inserta un null, pero la columna esta definida como
> tipo 't_dom' el cual no debe admitir nulos. Si en vez de ese update
> haces este: "update test2 set dom=NULL;
2013/5/3 Alvaro Herrera :
> Oswaldo escribió:
>
>>
>> En el resultado final la columna 'dom' tiene un valor NULL cuando
>> según las reglas definidas esto no deberia ser posible y se deberia
>> haber producido una excepción.
>
> Hola, no tengo claro que esto sea un bug, pero como es un caso de bord
Oswaldo escribió:
> Para reproducirlo ejecutar esta secuencia:
>
> begin;
>
> create domain t_dom as varchar default '' not null;
>
> create table test1 (id int, dom t_dom);
> create table test2 (id int, dom t_dom);
>
> insert into test2 (id) values (1);
> update test2 set dom = (select dom fr
El 03/05/2013 16:40, Martín Marqués escribió:
El día 3 de mayo de 2013 08:43, Oswaldo escribió:
Hola,
Creo que he detectado un bug, pero antes de reportarlo os agradecería
comprobaseis si la demostración es correcta y si también sucede en otras
versiones de postgres. También desconozco si es u
El día 3 de mayo de 2013 08:43, Oswaldo escribió:
> Hola,
>
> Creo que he detectado un bug, pero antes de reportarlo os agradecería
> comprobaseis si la demostración es correcta y si también sucede en otras
> versiones de postgres. También desconozco si es un bug ya conocido.
>
[.]
> Para rep
Hola,
Creo que he detectado un bug, pero antes de reportarlo os agradecería
comprobaseis si la demostración es correcta y si también sucede en otras
versiones de postgres. También desconozco si es un bug ya conocido.
La comprobación la he realizado en la version 9.1.9 sobre debian 32 bits
y
2011/10/31 Jaime Casanova :
> 2011/10/31 Daymel Bonne Solís :
>>
>> Esto debe ser un bug, aqui se debe lanzar un error, pues se consulta una
>> columna en la tabla foo que no existe. Que creen??
>>
>
> en mi opinion, si es un bug. voy a reportarlo a la lista -hackers a
> menos que tu desees hacerlo
2011/10/31 Daymel Bonne Solís :
>
> Esto debe ser un bug, aqui se debe lanzar un error, pues se consulta una
> columna en la tabla foo que no existe. Que creen??
>
en mi opinion, si es un bug. voy a reportarlo a la lista -hackers a
menos que tu desees hacerlo (o puedes usar la página web
http://ww
Probando algunas ideas, me encontré esto y me resultó extraño:
create table foo (i int);
insert into foo select * from generate_series(1,10);
create or replace function foovalues(value integer)
returns table(foo_values integer)
language plpgsql
as $function$
begin
/*
* Consulta mal elabor
De acuerdo con Alvaro.
Debería ser más estricta la sintaxis aunque algunas veces se arman
unos berenjenales de SQL que fastidian permiten leer mejor la
sentencia y no equivocarse.
El día 6 de enero de 2010 19:49, Alvaro Herrera
escribió:
> Jaime Casanova escribió:
>> 2010/1/6 Alvaro Herrera :
>>
Jaime Casanova escribió:
> 2010/1/6 Alvaro Herrera :
> >
> > De que es lamentable que sea así, estoy de acuerdo, pero como ya dije no
> > es un error de Postgres sino de la definición del lenguaje SQL.
>
> no me parece lamentable, eso permite que pueda hacer calculos dentro
> la subconsulta usando
2010/1/6 Alvaro Herrera :
>
> De que es lamentable que sea así, estoy de acuerdo, pero como ya dije no
> es un error de Postgres sino de la definición del lenguaje SQL.
>
no me parece lamentable, eso permite que pueda hacer calculos dentro
la subconsulta usando valores de la consulta mas externa
> El día 6 de enero de 2010 16:34, Ricardo Conde
> 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'
>
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 precisa
El 6 de enero de 2010 18:46, Alvaro Herrera escribió:
> Jose Luis Balle escribió:
>
> > --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
> > tabl
Jose Luis Balle escribió:
> --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 W
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 un
20 matches
Mail list logo
