Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: frank(at)exit(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.)
Date: 2000-04-24 22:00:41
Message-ID: 1791.956613641@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>> Currently, if you specify an index opclass then the system assumes that
>> you know what you are doing; there is no cross-check to see if the
>> chosen operators will work with the column datatype. That bothers me,
>> but I hesitate to insert a type-compatibility check; I wonder whether
>> there might be legitimate uses of comparison operators that would fail
>> a normal type-compatibility check against the column datatype.

It'd be sufficient to prevent crashes if we checked that the actual
data type of the column is binary-compatible with the declared input
type of the operators associated with the opclass. This wouldn't take
much additional code, either.

I'm still worried that there might be useful applications for index
opclasses that are not marked binary-compatible with the column data
type. But I don't have any examples at hand, and preventing crashes due
to user error is probably more important than allowing people to play
type-cheat games. (Besides, if you have an example where this really
works, you could evade the check by creating additional pg_proc entries
pointing at the same executable code but showing the desired data type
as the input type...)

Unless someone comes up with a counterexample, I'll put in a cross-check
that works like this.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message James Finch 2000-04-24 22:40:44 Bogus reporting of non-null value in function call.
Previous Message Frank Mayhar 2000-04-24 18:49:36 Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.)