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