Skip site navigation (1) Skip section navigation (2)

RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Nicolas Huillard" <nhuillard(at)ghs(dot)fr>, <pgsql-general(at)hub(dot)org>, <pgsql-sql(at)hub(dot)org>
Subject: RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
Date: 2000-01-27 23:59:23
Message-ID: 000301bf6922$88c54f20$ (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackerspgsql-sql
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > -----Original Message-----
> > > From: owner-pgsql-general(at)postgresql(dot)org
> > > [mailto:owner-pgsql-general(at)postgresql(dot)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.


Hiroshi Inoue

In response to

pgsql-hackers by date

Next:From: Chris BitmeadDate: 2000-01-28 00:03:53
Subject: Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns)
Previous:From: Tom LaneDate: 2000-01-27 23:09:26
Subject: Re: [HACKERS] Length of OID

pgsql-sql by date

Next:From: Philip WarnerDate: 2000-01-28 01:21:18
Subject: Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace
Previous:From: Vince GonzalezDate: 2000-01-27 23:42:54
Subject: Re: [SQL] User-defined error messages/codes

pgsql-general by date

Next:From: Ed LoehrDate: 2000-01-28 00:52:15
Subject: Re: [GENERAL] Large Functions and Index Rebuild
Previous:From: Peter EisentrautDate: 2000-01-27 22:27:35
Subject: Re: [GENERAL] Creating groups and granting privs to it

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group