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$2801007e@tpf.co.jp (view raw or flat)
Thread:
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.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

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-2014 The PostgreSQL Global Development Group