| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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-15 13:04:22 |
| Message-ID: | 20101015130422.GP26232@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
KaiGai,
* KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
> However, it requires the plugin modules need to know everything;
> such as what is visible/invisible. It seems to me too closely-
> coupled interface.
I agree with Robert on this one. We're not trying to design a wholly
independent security module system for any project to pick up and use
here. We're discussing hooks to go into PostgreSQL to support a
PostgreSQL security module. In other words, I don't think we need to
worry over if the PG-SELinux security module could be re-used for
another project or is too "PG specific". If it's *not* very PG
specific then something is wrong.
The issues we're talking about with regard to MVCC, visibility, etc,
would all be applicable to any serious database anyway.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-10-15 13:22:46 | Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch |
| Previous Message | Fujii Masao | 2010-10-15 12:41:42 | Timeout and wait-forever in sync rep |