Re: Prep object creation hooks, and related sepgsql updates
Kohei KaiGai <kaigai@kaigai.gr.jp>
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2011-12-05T13:54:09Z
Lists: pgsql-hackers
Attachments
- pgsql-v9.2-sepgsql-create-permissions-part-4.v2.proc.patch (application/octet-stream) patch v9
- pgsql-v9.2-sepgsql-create-permissions-part-2.v2.schema.patch (application/octet-stream) patch v9
- pgsql-v9.2-sepgsql-create-permissions-part-3.v2.relation.patch (application/octet-stream) patch v9
- pgsql-v9.2-sepgsql-create-permissions-part-1.v2.database.patch (application/octet-stream) patch v9
The attached patches are revised ones. I added explanations of DDL permissions on creation time added by these patches, and added a few regression test cases. Thanks, 2011/12/3 Kohei KaiGai <kaigai@kaigai.gr.jp>: > 2011/12/3 Robert Haas <robertmhaas@gmail.com>: >> On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >>> At least, it is working. However, it is not a perfect solution to the >>> future updates >>> of code paths in the core. >> >> Hmm. So, do you want this committed? If so, I think the major thing >> it lacks is documentation. >> >> I can't help noticing that this amounts, altogether, to less than 600 >> lines of code. I am not sure what your hesitation in taking this >> approach is. Certainly, there are things not to like in here, but >> I've seen a lot worse, and you can always refine it later. For a >> first cut, why not? Even if you had the absolutely perfect hooks in >> core, how much would it save compared to what's here now? How >> different would your ideal implementation be from what you've done >> here? >> > You are likely right. Even if the hook provides sepgsql enough > contextual information, it might means maintenance burden being > moved to the core from sepgsql, as we discussed before. > OK, I'd like to go with this approach. I'll try to update documentation > stuff and regression test cases, so please wait for a few days. > > Thanks, > >> As regards future updates of code paths in core, nothing in here looks >> terribly likely to get broken; or at least if it does then I think >> quite a lot of other things will get broken, too. Anything we do has >> some maintenance burden, and this doesn't look particularly bad to me. >> >> -- >> Robert Haas >> EnterpriseDB: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company > > > > -- > KaiGai Kohei <kaigai@kaigai.gr.jp> -- KaiGai Kohei <kaigai@kaigai.gr.jp>