Re: Prep object creation hooks, and related sepgsql updates

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

In response to

Responses

Browse pgsql-hackers by date

  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