From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, marc(at)bloodnok(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Fix leaky VIEWs for RLS |
Date: | 2010-06-04 19:33:29 |
Message-ID: | 22280.1275680009@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-04 19:35:29 | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Previous Message | Dave Page | 2010-06-04 18:43:20 | Re: Did we really want to force an initdb in beta2? |