Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.)
Date
Msg-id 1791.956613641@sss.pgh.pa.us
Whole thread Raw
In response to Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.)  (Frank Mayhar <frank@exit.com>)
List 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

pgsql-bugs by date:

Previous
From: Frank Mayhar
Date:
Subject: Re: Index opclass checking (was Re: Crash in PostgreSQL 7.0.b5.)
Next
From: "James Finch"
Date:
Subject: Bogus reporting of non-null value in function call.