RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
От | Hiroshi Inoue |
---|---|
Тема | RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 |
Дата | |
Msg-id | 000301bf6922$88c54f20$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-general |
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > > -----Original Message----- > > > From: owner-pgsql-general@postgresql.org > > > [mailto:owner-pgsql-general@postgresql.org]On Behalf Of > Nicolas Huillard > > > > > > I have a DB with is updated using MS Access. Primary keys are > > > Int4 with default random values ("Num_roAuto" + "Al_atoire" > in Access). > > > The DB is migrated as-is in Postgres, with tbl_prod.cle_prod > > > field containing values from -2057496808 to 2139583719. > > > When I SELECT in the table, using the INT4 cle_prod value, PG > > > doesn't find the tuple. When I SELECT using the VARCHAR(10) > > > ref_prod value, PG finds the tuple, and show the right value for > > > the cle_prod filed : the same as the one I SELECTed for... > > > > > > This sounds like the long negative integer values given in PSQL > > > is not converted correctly while executing. > > > Using a long positive integer value, all works like a charm... > > > > > > Below is the queries type sto sho what append. > > > I'm using Postgres 6.5.2 from the RPMs. > > > > > > > Could you try the follwoing patch ? > > Hiroshi, I don't see this in the main tree, nor do I see it having been > requested for application. Should I apply it? > Recently I have often seen this kind of bug reports though I don't know why * recently *. This is the second time I sent the patch but I have seen no reply. Anyway,this is clearly a bug. I could commit it to current tree but couldn't commit to REL tree because I don't maintain REL tree. Moreover int42cmp/int24cmp seems to have similar bugs and we had better check comparison functions again. I'm happy if you could commit it to both trees. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-general по дате отправления: