> -----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
