Re: security hook on table creation
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>, PgSQL-Hackers <pgsql-hackers@postgresql.org>, Joshua Brindle <method@manicmethod.com>, "David P. Quigley" <dpquigl@tycho.nsa.gov>
Date: 2010-10-01T02:23:30Z
Lists: pgsql-hackers
On Sep 30, 2010, at 9:01 PM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: > (2010/10/01 3:09), Robert Haas wrote: >> 2010/9/29 KaiGai Kohei<kaigai@ak.jp.nec.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. ...Robert