On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers