Re: Column-Level Privileges

Stephen Frost <sfrost(at)snowman(dot)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