Skip site navigation (1) Skip section navigation (2)

Re: Column-Level Privileges

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: sfrost(at)snowman(dot)net, pgsql-hackers(at)postgresql(dot)org, Markus Wanner <markus(at)bluegap(dot)ch>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: Column-Level Privileges
Date: 2009-01-21 03:35:02
Message-ID: 9602.1232508902@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> Stephen Frost wrote:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> 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).
>> 
>> Honestly, I like this approach.

> I agree with Stephen's opinion.
> Indeed, the walker approach requires additional steps during query
> parsing, but the code obviousness is a significant factor from the
> point of view of security.

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.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2009-01-21 03:45:16
Subject: Re: Column-Level Privileges
Previous:From: KaiGai KoheiDate: 2009-01-21 03:02:58
Subject: Re: Column-Level Privileges

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group