From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prep object creation hooks, and related sepgsql updates |
Date: | 2011-12-05 13:54:09 |
Message-ID: | CADyhKSUwK1TNioAYwQeEnHEFy6zarRAAUn34ea8A4UQ5jPu-HQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)kaigai(dot)gr(dot)jp>:
> 2011/12/3 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
pgsql-v9.2-sepgsql-create-permissions-part-4.v2.proc.patch | application/octet-stream | 5.8 KB |
pgsql-v9.2-sepgsql-create-permissions-part-2.v2.schema.patch | application/octet-stream | 4.1 KB |
pgsql-v9.2-sepgsql-create-permissions-part-3.v2.relation.patch | application/octet-stream | 17.3 KB |
pgsql-v9.2-sepgsql-create-permissions-part-1.v2.database.patch | application/octet-stream | 13.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2011-12-05 14:01:52 | Re: planner fails on HEAD |
Previous Message | Oleg Bartunov | 2011-12-05 13:49:45 | Re: WIP: SP-GiST, Space-Partitioned GiST |