Stephen Frost wrote: > * Tom Lane (t...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
