On 04/06/10 22:33, Tom Lane wrote:
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 can't take that example seriously. First of all, tacking a collation
specifier to text values would be an awful hack. Secondly, it would be a
bad idea to define the b-tree comparison operators to throw an error; it
would be a lot more useful to impose an arbitrary order on the
collations, so that all values with collation A are considered smaller
than values with collation B. We do that for types like box; smaller or
greater than don't make much sense for boxes, but we implement them in a
pretty arbitrary way anyway to make it possible to build a b-tree index
on them, and for the planner to use merge joins on them, and implement
DISTINCT using sort etc.
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...
Hash seems safe too. Don't merge joins just use the default b-tree operator?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
