From: Ryan Bradetich <rbradetich@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Subject: Re: [PgFoundry] Unsigned Data Types [1 of 2]
Date: Tue, 9 Sep 2008 08:14:59 -0700
Message-ID: <e739902b0809090814j55a75d6dm213432b87f4b0c5f@mail.gmail.com> (raw)
In-Reply-To: <22555.1220962305@sss.pgh.pa.us>
References: <e739902b0808311335l1ad5d425r2704429c386f2f88@mail.gmail.com>
<3073cc9b0809061341q5c747488i85491e4c8e2420ba@mail.gmail.com>
<3073cc9b0809062330o62fd74dax74b1730cedc0fbb9@mail.gmail.com>
<e739902b0809082008p6c694a20ufd526d1ce5d46750@mail.gmail.com>
<3073cc9b0809082254g789a7f14x45e9d416925b1057@mail.gmail.com>
<e739902b0809082325s69c21814mbc0dc8dfd6ebfec6@mail.gmail.com>
<22555.1220962305@sss.pgh.pa.us>
Hello Tom,
On Tue, Sep 9, 2008 at 5:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Ryan Bradetich" <rbradetich@gmail.com> writes:
>> I am assuming you are seeing this error in the uint_test1.sql:
>> ERROR: could not find hash function for hash operator 16524
>> I can bypass the error in uint_test1.sql by disabling the hash joins.
>> I am going to dig in and figure out why the hashjoin operation is broken.
>
> Well, the cause of that one would've been marking an operator as HASHES
> without providing a hash opclass to back it up.
Actually I did provide a hash operator class in the patch:
CREATE OPERATOR CLASS uint4_ops
DEFAULT FOR TYPE uint4 USING HASH AS
OPERATOR 1 =,
FUNCTION 1 hashuint4(uint4);
This only provides the operator class for uint4 eq uint4. Jaime's test case
was uint4 eq int4 which I did not have an operator class for. I was able to fix
this test case by adding the int4 eq uint4 operator like this:
CREATE OPERATOR CLASS uint4_ops
DEFAULT FOR TYPE uint4 USING HASH FAMILY unsigned_integer_ops AS
OPERATOR 1 =,
FUNCTION 1 hashuint4(uint4);
ALTER OPERATOR FAMILY unsigned_integer_ops USING HASH ADD
OPERATOR 1 = (int4, uint4),
FUNCTION 1 hashuint4_from_int4(int4);
I tested uint4 eq int4 and int4 eq uint4 and this one additional hash operator
handles them both.
[NOTE: The other solution was to cast foo to the uint4 data type.]
I am working on adding support for the int4 eq uint2 and int4 eq uint1 cases
as well. I am running into an error when I add support for these hash operator
classes that I am not quite ready to post about yet (I want to look a
bit more first).
> IIRC the test case involved ">"? That shouldn't even be marked HASHES
> anyway ...
That error was in the uint_test2 test case Jaime provided.
This test case looks like:
drop table if exists t1_uint4;
create table t1_uint4 (f1 uint4 primary key);
insert into t1_uint4 select generate_series(1, 255);
analyze t1_uint4;
select * from t1_uint4, generate_series(1, 10) as foo where t1_uint4.f1 = foo;
Thanks,
- Ryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: rbradetich@gmail.com, tgl@sss.pgh.pa.us, jcasanov@systemguards.com.ec
Subject: Re: [PgFoundry] Unsigned Data Types [1 of 2]
In-Reply-To: <e739902b0809090814j55a75d6dm213432b87f4b0c5f@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox