Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > On 04/06/10 17:33, Tom Lane wrote: >> Maybe the entire idea is unworkable. I certainly don't find any comfort >> in your proposal in the above-referenced message to trust index >> operators; where is it written that those don't throw errors?
> Let's consider b-tree operators for an index on the secure table, for > starters. Surely a b-tree index comparison operator can't throw an error > on any value that's in the table already, you would've gotten an error > trying to insert that. Man, are *you* trusting. A counterexample: suppose we had a form of type "text" that carried a collation specifier internally, and the comparison routine threw an error if asked to compare values with incompatible specifiers. An index built on a column of all the same collation would work fine. A query that tried to compare against a constant of a different collation would throw an error. > I'm not sure. But indexable > operations are what we care about the most; the order of executing those > determines if you can use an index scan or not. Personally, I care just as much about hash and merge join operators... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers