Thread

1. sepgsql: fix relkind handling on foreign tables

   Kohei KaiGai <kaigai@kaigai.gr.jp> — 2011-05-22T09:52:39Z

   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>
   

2. Re: sepgsql: fix relkind handling on foreign tables

   Robert Haas <robertmhaas@gmail.com> — 2011-05-23T18:26:15Z

   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
   
   

3. Re: sepgsql: fix relkind handling on foreign tables

   Kohei KaiGai <kaigai@kaigai.gr.jp> — 2011-05-24T10:57:26Z

   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>
   
   

4. Re: sepgsql: fix relkind handling on foreign tables

   Robert Haas <robertmhaas@gmail.com> — 2011-05-24T11:56:53Z

   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