Stephen Frost <sfr...@snowman.net> writes: > Attached is an updated patch for column-level privileges.
I'm working on getting this committed. I've run into a major stumbling block in the parse-time marking of columns for SELECT privileges: the do-it-as-the-Vars-get-transformed approach basically doesn't work as-is. The problem comes from whole-row Vars referencing JOIN relations. We already talked about the need to mark column 0 as referenced for a whole-row Var, but if the Var is referencing a join then the correct thing is to recursively mark column 0 of the two input relations. (The existing patch simply crashes in this case ...) The problem is that there is no reliable way to identify the two input relations given only the join RTE. The normal thing we do is to dig in the query jointree for the JoinExpr, but during parse analysis the jointree is still being built and we don't have access to it :-(. The failure case would be where an upper JOIN/ON clause contains a whole-row reference to a contained JOIN relation. I considered a couple of alternatives: * Modify the recursion in transformFromClauseItem so that we can somehow get at the partially-built jointree for the current join item. Ugly and probably fragile. * Depend on the join's joinaliasvars list to contain references to both sides of the join. This fails in various corner cases, for instance LEFT NATURAL JOIN where every column of the righthand rel is a common column. * Add the left and right input RT indexes to join RTEs, so that we can get hold of them without needing to search the jointree. Kind of annoying to do this just for the one usage, mainly because there's a lot of infrastructure needed to update such entries during rewriter/planner manipulations. (Which would all be 100% useless anyway if the fields are only examined by the parser, but I dislike the idea of having RTE fields that aren't valid after parse time ...) On the whole I think we have to go back to the original plan of recursively searching the query's expressions after we've finished all the transformations (and have a completed jointree to refer to). This is slightly annoying on the grounds of adding parsing overhead that's completely useless unless per-column privileges are in use. On the other hand, none of the workable alternatives are exactly overhead-free either. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers