Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7DAC664FD33 for ; Sun, 7 Sep 2008 13:07:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 87754-10 for ; Sun, 7 Sep 2008 13:07:21 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id CB51664FD16 for ; Sun, 7 Sep 2008 13:07:20 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m87G7ImJ014576; Sun, 7 Sep 2008 12:07:18 -0400 (EDT) To: "Jaime Casanova" cc: "Ryan Bradetich" , pgsql-patches Subject: Re: [PgFoundry] Unsigned Data Types [1 of 2] In-reply-to: <3073cc9b0809070713s1df16d8dlb3be457b3584ba5c@mail.gmail.com> References: <3073cc9b0809061341q5c747488i85491e4c8e2420ba@mail.gmail.com> <3073cc9b0809062330o62fd74dax74b1730cedc0fbb9@mail.gmail.com> <8731.1220773267@sss.pgh.pa.us> <3073cc9b0809070713s1df16d8dlb3be457b3584ba5c@mail.gmail.com> Comments: In-reply-to "Jaime Casanova" message dated "Sun, 07 Sep 2008 09:13:39 -0500" Date: Sun, 07 Sep 2008 12:07:18 -0400 Message-ID: <14575.1220803638@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/86 X-Sequence-Number: 7101 "Jaime Casanova" writes: > On Sun, Sep 7, 2008 at 2:41 AM, Tom Lane wrote: >> That obviously isn't supposed to happen. Where's it coming from >> exactly? > convert_numeric_to_scalar() in src/backend/utils/adt/selfuncs.c > the problem seems to be that we are asking for each type of numeric > and of course that doesn't know nothing about unsigned integers so its > treating it as a non-numeric. Ah. The scalarltsel/scalargtsel stuff has always been a bit bogus for cross-type comparisons; it assumes it will know both or neither of the two datatypes. So you can get away with using those functions for uint > uint (although they won't be very bright about it); but using them for uint > int fails outright. If you read the comments around that stuff it leaves quite a lot to be desired, but I don't really have better ideas at the moment. The best near-term solution for the uint module is probably not to rely on scalarltsel/scalargtsel for uint comparisons, but to make its own selectivity functions that know the uint types plus whatever standard types you want to have comparisons with. regards, tom lane