[BUGS] BUG #4816: NOT IN clause, doesn't work
The following bug has been logged online: Bug reference: 4816 Logged by: jose soares Email address: jose.sao...@sferacarta.com PostgreSQL version: 8.3.5 Operating system: x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.2-1) 4.3.2 Description:NOT IN clause, doesn't work Details: Hello all, I'm trying a NOT IN clause, but seems it doesn't work. Please take a look: mydb=# select distinct id from psop where id_ua = 72492; id --- 56844 67953 67955 (3 rows) mydb=# select distinct id_sop from scad where id_ua = 72492; 56844 67953 (3 rows) mydb=# select distinct id from psop where id_ua = 72492 and id not in (select distinct id_sop from scad where id_ua = 72492); id (0 rows) mydb=# select distinct id from psop where id_ua = 72492 and id not in (56844,67953); id --- 67955 (1 row) What's wrong with those selects? j -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] subselects doesn't work in v7.0.3
Andrew McMillan wrote: > [EMAIL PROTECTED] wrote: > > > > jose ([EMAIL PROTECTED]) reports a bug with a severity of 2 > > The lower the number the more severe it is. > > > > Short Description > > subselects doesn't work in v7.0.3 > > > > Long Description > > Version: PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.95.2 > > > > - I'm trying the following query in a table with 1973093 rows: > > > > EXPLAIN select count(*) > >from marche > >where ristampa = 'S' > >and marca in > >( > >select marca from marche where ristampa is null and > >data_lotto between '1998/07/01' and '1999/01/31' > >); > > > > NOTICE: QUERY PLAN: > > Aggregate (cost=98854229180.08..98854229180.08 rows=1 width=4) > > -> Seq Scan on marche (cost=0.00..98854229130.75 rows=19731 width=4) > > SubPlan > > -> Materialize (cost=50101.13..50101.13 rows=6577 width=12) > > -> Seq Scan on marche (cost=0.00..50101.13 rows=6577 width=12) > > EXPLAIN > > > > - but it takes to many time: (after about 16 hours I interrupt the query) > > This is a known bug with IN ( ... ) and the use of indexes - you would > get better results using EXISTS. Yes. EXISTS works. PostgreSQL takes 9.720 secs against DBMaker 7.145 secs Thank you very much Jose' > > > Cheers, > Andrew. > -- > _ >Andrew McMillan, e-mail: [EMAIL PROTECTED] > Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington > Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
[BUGS] BUG #5554: PostgreSQL 8.4.0 doesn't update my table
The following bug has been logged online: Bug reference: 5554 Logged by: jose soares Email address: jose.soa...@sferacarta.com PostgreSQL version: 8.4.0 Operating system: Linux Debian 4.3.3-13 64-bit Description:PostgreSQL 8.4.0 doesn't update my table Details: I all, I found a strange behavior in my DB, I have a table which Pg isn't be able to update. Take a look... # select esito from scadenziario where id=564481; esito --- C (1 row) # update scadenziario set esito='N' where id=564481; UPDATE 1 # select esito from scadenziario where id=564481; esito --- C (1 row) I already tried a vacumm without success, this behavior is the same for all table's columns. what's wrong? thank you for any help. j -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6036: why a REAL should be queried as a string?
The following bug has been logged online: Bug reference: 6036 Logged by: jose soares Email address: jose.soa...@sferacarta.com PostgreSQL version: 8.4.4 Operating system: x86_64-pc-linux-gnu Description:why a REAL should be queried as a string? Details: I'd like to to report this strange behavior, that I think is a bug... # \d frazione Table "public.frazione" Column | Type | Modifiers +-+ id | integer | not null importo| real| not null # update frazione set importo=0.833 where id=549; UPDATE 1 # select * from frazione where importo=0.833; id | importo +- (0 rows) # select * from frazione where importo='0.833'; id | importo -+-- 549 | 0.833 (1 rows) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6669: unique index w/ multiple columns and NULLs
The following bug has been logged on the website: Bug reference: 6669 Logged by: jose soares Email address: jose.soa...@sferacarta.com PostgreSQL version: 8.4.8 Operating system: x86_64-pc-linux-gnu, debian Description: Hi, I think I have found an error in pg or at least inconsistency, take a look at this. I created an unique index on two columns and pg let me enter repeated values as NULLs (unknown value), When I ask pg to tell me if there are repetitions n this index (with group by), the inconsistency becomes apparent. # create table test(id int, data date, code int); CREATE TABLE # create UNIQUE index unica on test(data,code); CREATE INDEX # \d test Table "public.test" Column | Type | Modifiers +-+--- id | integer | data | date| code | integer | Indexes: "unica" UNIQUE, btree (data, code) # insert into test values(1,current_date); INSERT 0 1 # insert into test values(2,current_date); INSERT 0 1 # insert into test values(3,current_date); INSERT 0 1 sicer_forli=# select current_date,code, count(*) from test group by 1,2; date| code | count +--+--- 31-05-2012 | | 3 (1 row) ps: Oracle don't allows to insert two NULLs in such column. I don't know which of them is SQL Standard, but in this case oracle is not inconsistent. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
