Thread: sepgsql: fix relkind handling on foreign tables
The attached patch fixes up case handling in foreign tables. Now it didn't assign security label on foreign table on its creation time, and didn't check access rights on the dml hook. This patch fixes these problems; It allows foreign tables default labeling and access checks as db_table object class. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > The attached patch fixes up case handling in foreign tables. > > Now it didn't assign security label on foreign table on its creation > time, and didn't check access rights on the dml hook. > This patch fixes these problems; It allows foreign tables default > labeling and access checks as db_table object class. A foreign table is really more like a view, or a function call. Are you sure you want to handle it like a table? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2011/5/23 Robert Haas <robertmhaas@gmail.com>: > On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> The attached patch fixes up case handling in foreign tables. >> >> Now it didn't assign security label on foreign table on its creation >> time, and didn't check access rights on the dml hook. >> This patch fixes these problems; It allows foreign tables default >> labeling and access checks as db_table object class. > > A foreign table is really more like a view, or a function call. Are > you sure you want to handle it like a table? > It might be a tentative solution, so I'll want to cancel this patch. Its nature is indeed more similar to function call rather than tables, but not a function itself. So, it might be a better idea to define its own object class such as "db_foreign_table" instead of existing object classes. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
On Tue, May 24, 2011 at 6:57 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > 2011/5/23 Robert Haas <robertmhaas@gmail.com>: >> On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >>> The attached patch fixes up case handling in foreign tables. >>> >>> Now it didn't assign security label on foreign table on its creation >>> time, and didn't check access rights on the dml hook. >>> This patch fixes these problems; It allows foreign tables default >>> labeling and access checks as db_table object class. >> >> A foreign table is really more like a view, or a function call. Are >> you sure you want to handle it like a table? >> > It might be a tentative solution, so I'll want to cancel this patch. > > Its nature is indeed more similar to function call rather than tables, > but not a function itself. So, it might be a better idea to define its > own object class such as "db_foreign_table" instead of existing > object classes. Perhaps. Or else use db_view. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company