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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-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

Browse pgsql-general by date

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

Browse pgsql-hackers by date

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

Browse pgsql-sql by date

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