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