Peter Eisentraut wrote: > On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote: >> CREATE TABLE tbl_p (int a, int b); >> CREATE TABLE tbl_c (int x) INHERITS(tbl_p); >> >> SELECT a,b FROM tbl_p; --> It selects data from only tbl_p. >> It is reasonable to bypass checks on tbl_c. >> SELECT b,x FROM tbl_c; --> It selects data from tbl_p and tbl_c >> concurrently, >> if we consider the inherited columns are a part >> of >> the parent table. > > I think you need to distinguish between the definition of columns and > the data in the columns. tbl_c has inherited the definition of the > columns from tbl_p, but the data is part of tbl_c, not tbl_p. So there > is not reason for this second query to ask tbl_p for permission, because > it does not touch data in tbl_p at all.
Yes, I can understand the second query selects data stored within only tbl_c in this case, not tbl_p, even if tbl_c inherits its definitions from the parent. However, this perspective may be inconsistent to the idea to bypass permission checks on the child (tbl_c) when we select data from the parent (tbl_p), because the first query also fetches data stored within the tbl_c, not only the tbl_p. IMO, if we adopt the perspective which considers the access control depends on the physical location, the current implementation works fine. However, this idea proposed a different perspective. It allows to bypass permission checks on the child tables, because the child has identical definition with its parent and these are a part of the parent table. If so, I think this perspective should be ensured without any exception. BTW, I basically think this perspective change is better. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
