Skip site navigation (1) Skip section navigation (2)

Re: security hook on table creation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, PgSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <method(at)manicmethod(dot)com>, "David P(dot) Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov>
Subject: Re: security hook on table creation
Date: 2010-10-01 02:23:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sep 30, 2010, at 9:01 PM, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> (2010/10/01 3:09), Robert Haas wrote:
>> 2010/9/29 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>> In addition, I want to give these entrypoints its name which
>>> represents an appropriate purpose of the hook, rather than
>>> a uniformed one.
>> It sounds like you're proposing to create a vast number of hooks
>> rather than just one.  If we have ~20 object types in the system,
>> that's 40 hooks just for create and drop, and then many more to handle
>> comment, alter (perhaps in various flavors), etc.  I'm pretty
>> unexcited about that.  The main hook function can always dispatch
>> internally if it so desires, but I don't see any benefit to forcing
>> people to write the code that way.
> What I proposed is to create just one hook and wrapper functions
> with appropriate name; that calls the hook with appropriate parameters,
> such as SearchSysCache1, 2, 3 and 4.

Seems like you'd end up creating a lot of macros that were only used once.

> BTW, as an aside, the SearchSysCacheX() interface also inspired me.
> If the hook function can deliver a few Datum values depending on object
> types and event types, it may allows the main hook to handle most of
> security checks, even if we need to add various flavors.

Good idea.  Let's leave that out for the first version of this, though.


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-10-01 02:29:56
Subject: Re: patch: SQL/MED(FDW) DDL
Previous:From: Robert HaasDate: 2010-10-01 02:20:48
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group