On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> [ new patch, with example query plans ]
I like the look of those query plans.
Redefining the RangeTblEntry's relid field to be valid for either a
table or a subquery that originated from a view seems problematic to
me, though. For one thing, it's hard to say how much other code
assumes that field to be valid only for a table. For example, you
didn't update _readRangeTblEntry(), and I wouldn't bet on that being
the only place that needs fixing. For another thing, instead of
changing the meaning of the relid field, you could just leave that
alone and instead add a "bool security_barrier field" that caches the
answer; ApplyRetrieveRule() has the Relation object and could set that
field appropriately, and then subquery_was_security_barrier() wouldn't
need a syscache lookup.
Now, the obvious objection is that the security-barrier attribute
might change between the time the RTE is created and the time that it
gets used. But if that's a danger, then presumably the whole view
could also change, in which case the Query object would be pointing to
the wrong data anyway. I'm not sure I fully understand the details
here, but it seems like it ought to be safe to cache the
security_barrier attribute any place it's safe to cache the Query
itself. It certainly doesn't seem right to think that we might end up
using a new value of the security_barrier attribute with an old query,
or the other way around. So something seems funky here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
