Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> On looking closer, though, it's *still* messy and unobvious :-(.
>> There is no single place in the parser where we have the complete
>> multi-level query tree available in a convenient form for this sort of
>> postprocessing.
>
> That's unfortunate. :/
>
>> I've thought of a less painful variant of my third option: instead of
>> making a permanent addition to RangeTblEntry, we can have a transient
>> data structure attached to ParseState that lets us find the JoinExpr
>> nodes for already-parsed joins. I'm going to try that next.
>
> Sounds reasonable. I'd be happy to help if there's anything useful I
> can do at this point.
I also think it can be a reasonable approach.
However, as an aside, it will not be a help for SE-PostgreSQL, because
it checks Query tree *after* it passed through the rewriter stage, so
ParseState is already released. :-(
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/proxy.c#395
QueryRewrite()-> pgacePostQueryRewrite() -> sepgsqlPostQueryRewrite() -> walkQueryHelper() ->
walkVarHelper() -> wholeRefJoinWalker()
Yes, it is an optional facility and we assume performance is not first
priority for SE-PostgreSQL users. However, if its duration of life has
been expanded to the tail of rewriter, I would be also happy.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
